Problem: Currently have no way to verify integrity of my offline encrypted system. I would like to ensure the system hasn't been physically tampered with while I've been away from it.

(To clarify:while I am aware that the system cannot be modified without gaining access to the my encryption key. This question is to address the off-chance that the encryption is somehow bypassed. i.e. They gain access to my encryption key.)

Proposed solution: Hash the contents of the hard drive and have that hash added to a thumbdrive that I will maintain control of.


  1. How difficult would it be to obtain a hash for a harddrive before every system shutdown and have that hash added to a log on a thumbdrive that can be validated after every login?

  2. Would I need to have the system unmounted to ensure this method is valid?

  3. Is there already a prepackaged solution that you are aware of for this problem?


  1. I would need to ensure physical security of the thumbdrive to make sure the checksums match is valid (maintaining physical security of a keydrive is much easier than carrying a computer around with me)

  2. This method would probably be more easily implemented on virtual machines (though that doesn't do anything if the host is compromised).

  3. Having a Live Linux USB on the thumbdrive to create the hash on the unmounted drive may be a more simplistic method, although not quite as streamlined.

Other thoughts: I am aware that system encryption offers some level of integrity assurance. But in the off chance that encryption becomes violated, I would like to know.

OS: Arch Linux

  • Does the encryption you use not perform some type of integrity check? Could you elaborate on which encryption software you're using for FDE?
    – RoraΖ
    Nov 6, 2014 at 15:55
  • I'm currently using LVM over LUKS, This setup ensures full disk encryption, but does not perform integrity checking as far as I'm aware. Nov 6, 2014 at 16:00
  • Integrity of what? If the data has been altered without the encryption key, then the drive would be unusable.
    – schroeder
    Nov 6, 2014 at 16:05
  • ZFS and TahoeLAFS have some similar features. Nov 6, 2014 at 16:14
  • @schroeder - Clearly... As stated at the bottom of this post, the integrity check is to verify the systems integrity in the case that the encryption of the system is bypassed. (I.E. someone gains access to my encryption key.) Nov 6, 2014 at 16:15

2 Answers 2


Near impossible, or at least very difficult. First, there is too much data. It would take a VERY long time to compute a hash of the entire HDD every shutdown and again for every boot. You could alternately use chaining of hashes though to get around that, but it would require a specialized file system. Second however, even if you were willing to wait for a full hash or use a file system that does chaining like that, values are going to change during the boot process itself. Temp files will be created, paging files will change, etc, so it won't work on a system drive without a specialized boot loader on the USB stick that could validate from the earliest stages.

Either way, the hash is irrelevant if the encryption key is securely maintained. You can't meaningfully change encrypted data if you don't have the encryption key. You can corrupt it, but a basic parity check would find that kind of tampering. If the encryption key becomes compromised, you are screwed either way as your data could be read without altering the drive.

An elaborate attacker could also do something like loading in to firmware or memory before your hash can run and then replacing itself after your check, thus avoiding detection by this means (and altering the hash after the first time) unless you do some really elaborate custom mounting that will process everything from the HDD as untrusted and only load things which pass validation chaining.

It also is a lot easier if you are mounting it as an offline drive mounted after boot and can trust the hardware you are connecting to it since that doesn't require a trusted bootloader then. If you can't trust the hardware, bios and other system firmwares also become a concern.

Not much is out there to try to handle this situation as just about every threat model considers the system broken if the key is compromised.

  • While I understand your point that IF the key is properly maintained it make it much more difficult to violate the integrity of the system. In the off chance that encryption IS violated then I would like to have a method of knowing, that was the point of this post. To ensure integrity in the case of encryption failing. You do however made a good point in that the hashing of a whole system would take quite some time, it would make more sense to Hash specific files that would indicate possible system tampering. Nov 6, 2014 at 16:20
  • @JayHolister - yeah, individual file hashes would work, but now you need a much larger amount of data on the USB stick and probably some specialized mounting to verify it. You also have to be careful with how you mount the drive to make sure that the attacker can't use it to launch any attack on your system that would allow it to mask changes they made. Nov 6, 2014 at 16:23
  • Yeah, the drive would need to run in RAM, and not mount any drives. Though I'm still unsure how an attacker could mount an attack from the systems firmware. Could you elaborate on that? Nov 6, 2014 at 16:33
  • HDDs have firmware that governs how they operate. Someone could flash an alternate firmware that would mask their changes and tweak data in flight after verification. This could allow them to, say, alter an executable being loaded to turn it in to a root kit that would alter the behavior of your mounting, so you'd have to be very careful of how you mounted to prevent tampering from the HDD firmware. I don't know of anything that handles this kind of threat model as most models are built around the idea that a lost key is a broken system, rendering most of these concerns far less necessary. Nov 6, 2014 at 16:36
  • One thing that I see that would impact the drive hash solution is if you write your hash of your whole drive to your drive, then that will change what the hash will be next time you check. This problem might be solved by storing the hash on a different (unhashed) partition of the drive, or another storage device (perhaps even a specialized piece of hardware).
    – Jonathan
    Nov 7, 2014 at 20:48

An attacker would have to have access to the encryption key to decrypt the volume, modify a file, then re-encrypt. An attacker couldn't just modify the straight encrypted data. Then when you went to decrypt the data, the decryption would fail. As long as the encryption key is secure you shouldn't have any problems.

If you're worried about file integrity then there are programs like TripWire that can tell you when specific files have been modified on disk. It keeps hashes of files you tell it to care about. If one of them is changed on disk then this is logged. You would be able to check whenever you mount the volume if any files were changed. I think this would be your best option. Keep in mind that if the attacker has access to encryption keys, all of this can be modified while the drive is online.

To answer your questions specifically:

How difficult would it be to obtain a hash for a harddrive before every system shutdown and have that hash added to a log on a thumbdrive that can be validated after every login?

This would be severely impractical. You would have to hash the entire volume which is essentially an entire volume scan. This could take from 30 minutes to hours depending on the size of the drive.

Would I need to have the system unmounted to ensure this method is valid?

For the integrity check to be valid the drive would have to be online and mounted. However, an attacker could hide themselves while the drive is online. So they would be included in the integrity check. Kind of a who's on first situation there.

Is there already a prepackaged solution that you are aware of for this problem?

The short answer is no, not that I'm aware. To ensure the integrity of the drive it must be online and decrypted. But an attacker can hide themselves in the integrity check this way. You would want to do an offline integrity check, but then the drive is encrypted. I think you either choose the encryption, or choose the offline integrity. I believe it's impractical to have both.

I would be satisfied with the encryption option myself. Then I only have myself to blame if the encryption keys are compromised.

  • I'm aware that the encrypted system can't be modified without being decrypted, my point (As stated in the post) was that I would like to ensure integrity IF the systems encryption was bypassed. Nov 6, 2014 at 16:09
  • 2
    Then you would want to go with file integrity programs like TripWire.
    – RoraΖ
    Nov 6, 2014 at 16:10
  • @JayHolister I updated my answer to address your specific questions.
    – RoraΖ
    Nov 6, 2014 at 16:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .