Would it be possible to make a system dependent on two pieces of physical hardware to function?
What if you have a version of Ubuntu server edition running as a virtual machine, that will not unlock without a decrypting a flashdrive and passing a checksum verification on the flash drive?
a physical object and a checksum verification, with a password, to have Super user access would be next level, wouldn’t it?
The checksum would update on the machine itself and flash drive, if they were ever different, it could be set to delete everything, for example.
Attaching Any UID for example, would cause the checksum to fail. This way, no key loggers or other hacking tools could be inserted as UIDs without the flash drive being inserted first. After the flash drive is inserted, a keyboard or other device could be attached, and then a password entered.
Any time you want to design security systems, you should start by asking yourself what risk(s) you’re trying to mitigate. For example, if you insist on having a special device plugged in before the machine is usable, then you seem to want to protect the contents of that machine from someone who has physical access to it. What if they boot a RAMdisk-based “Live” OS and mount your drive rather than booting it? Or just take out the storage and plug it into another machine as secondary storage and copy the contents from it that way? If that’s a concern, then you really do need to be encrypting it to make that impossible. In that case, combining your special hardware token requirement with your disk encryption requirement would make more sense.
You can already LUKS encrypt your disk when installing Ubuntu, and then put a keyfile on a USB stick or enroll a pluggable HSM to supply the decryption key. If you want to do it at a virtual machine level, use hardware passthrough. Without having the key plugged in, you can’t decrypt the drive. You’ll also find systems like those manufactured by Purism, which can be purchased in conjunction with 2FA USB devices that have to be inserted in order to boot.
Thanks, and yes I am aware of several things you mentioned.
The purpose would be a physical USB to behave like a key with password to generate a signature. I was thinking that could be really useful because if I’m away from my terminal and someone somehow managed to access it, they might change something on the files system. There could be a log file, or a permission change that would be reflected in the checksum. If my computer was stolen, they couldn’t access anything on start up, instead without the presence of a physical device and a passcode it could start deleting everything, maybe even overclock things until the device overheats and destroys itself after deleting everything.
If they removed the hard drive, and attempted to use another device to gain access, that wouldn’t work either. Upon start up, it would start looking for a USB first.
This is because most systems on boot will allow by default, a user interface like a keyboard, but some things like a bad USB/keylogger /bash bunny mimic a keyboard, that’s the purpose of the physical device.
If I’m not mistaken, a hackers ability to gain access has allot to do with them being able to trick a target into thinking it is someone or something it is not.
So, even if the USB was recovered, and the computer was recovered, it would still require a password. If any data was manipulated at any point, it would result in a failed checksum. This way, if someone discovered the USB attempted to clone and then swap it to reverse engineer it, it would fail. If they gained access to either device and modified anything the checksum would fail.
If they removed the hard drive, and attempted to use another device to gain access, that wouldn’t work either. Upon start up, it would start looking for a USB first.
Someone can quite easily take the drive out of your computer and plug it into another computer as a secondary/auxiliary (non-boot) disk. If you don’t encrypt the content, then they have complete access to everything on the drive without booting from it, so your boot-time protections never have a chance to take effect.
If you do encrypt everything, then they can’t access anything on it without the necessary decryption key (which can be or be kept on a separate physical device), regardless of whether it’s installed in your machine or if they plug the drive into something else.
Yes, maybe I wasn’t clear about that. They could take it out and put it into another computer, and attempt to break the encryption definitely. That’s exactly what I was saying. But, if they try that, and while attempting to boot they begin doing anything at all before first installing the USB drive and decrypting it first, it would begin the process of self destruction.
Another issue is accessing the computer during a session, when the computer/hard drive has been decrypted. Encryption protects the device until the device is opened, then there is no encryption. Same effect could for the sudo command. Linux is a very hardened environment until sudo and a password is used, then superuser has all read and write privileges. From my understanding, this is why it isn’t recommended to do everything on your Linux system as the root user.
I think it would be very interesting, if you had a security feature like the one I mentioned, so that If the USB was pulled out it would log out immediately and begin a countdown to reinsert the drive, enter a password, and shut the system down normally. Failing to do that would set the destructive mechanism in motion. Like a “Dead man’s switch”