Forgot your password?
typodupeerror
Encryption

TrueCrypt Master Key Extraction and Volume Identification 222

Posted by Soulskill
from the be-sure-to-use-it-the-right-way dept.
An anonymous reader writes "The Volatility memory forensics project has developed plugins that can automatically find instances of Truecrypt within RAM dumps and extract the associated keys and parameters. Previous research in this area has focused specifically on AES keys and led to the development of tools such as aeskeyfind. The Volatility plugin takes a different approach by finding and analyzing the same data structures in memory that Truecrypt uses to manage encryption and decryption of data that is being read from and written to disk. With the creation of these plugins a wide range of investigators can now decrypt Truecrypt volumes regardless of the algorithm used (AES, Seperent, combinations of algos, etc.). Users of Truecrypt should be extra careful of physical security of their systems to prevent investigators from gaining access to the contents of physical memory."
This discussion has been archived. No new comments can be posted.

TrueCrypt Master Key Extraction and Volume Identification

Comments Filter:
  • by bazmail (764941) on Wednesday January 15, 2014 @07:18PM (#45970729)
    Don't people burn memory blocks any more? This is sensitive data handling 101.
    • by DigitAl56K (805623) on Wednesday January 15, 2014 @07:26PM (#45970795)

      TrueCrypt has to keep the keys somewhere so long as a volume is mounted. Whatever happens, so long as it's not currently on the CPU (and potentially even if it is), something that can read its data structures is always going to be able to find the keys in RAM if the structure is known. Maybe if TrueCrypt has some crazy polymorphic engine and corresponding polymorphic data structure that changed on every run it could get very difficult, but probably not impossible, to extract them.

      • by Anonymous Coward on Wednesday January 15, 2014 @07:33PM (#45970859)

        Also, you have to ask how much worth would that would be.

        If they have your RAM dump the securiy has been already lost.

      • Re: (Score:3, Interesting)

        by Penguinisto (415985)

        While not perfect, such activity can be mitigated. TruCrypt can be written to automatically unmount the 'drive' as the computer goes to sleep/hibernate/etc, and could even be written to plop the keys into a random section of RAM each time it re-connects. Hell, you could even rig an option to unmount the drive when the screensaver comes on.

        That would only leave the ability to access it when the computer is active - but then it's pretty much game-over in that situation anyway.

        • by avltree (3501127) on Wednesday January 15, 2014 @07:42PM (#45970951)
          "While not perfect, such activity can be mitigated. TruCrypt can be written to automatically unmount the 'drive' as the computer goes to sleep/hibernate/etc' for FDE, it does dismount and scrub the key during hibernation. Sleep is different though and RAM is not cleared during it. "and could even be written to plop the keys into a random section of RAM each time it re-connects." This doesn't really change anything. TC must still be able to find the key and the current drive version could be extracted from memory and reverse negineering to determine where the key currently is.
          • by mrchaotica (681592) * on Wednesday January 15, 2014 @07:49PM (#45970999)

            Not if it throws away the key and prompts you to re-enter it every time it wakes back up.

          • by MightyMartian (840721) on Wednesday January 15, 2014 @07:50PM (#45971027) Journal

            So ultimately, if you want to keep your data secure, you need to shut down your laptop at least several minutes before it could be potentially seized. I remember last year reading a piece about how even volatile RAM, if kept very cool, could be read with some fidelity even after a computer had been shut down, but these seem like lab conditions. I think we're along way from declaring disk encryption "crackable", providing appropriate measures are taken.

            • by Anonymous Coward on Wednesday January 15, 2014 @08:00PM (#45971089)

              Upon unmount, TC should write (and overwrite) lots of random junk to the ram it was using to store keys so you don't have to worry about stale ram recovery techniques.

            • by AmiMoJo (196126) *

              You can defend against such attacks with some work. First make sure that the BIOS is locked with a password and set to do a full memory test a boot. That way even if they grab the machine and hit the reset button to boot their malware CD/flash drive the BIOS will first erase the entire contents of RAM and they won't be able to stop it (make sure your BIOS doesn't allow the test to be cancelled). The password makes booting from CD/USB impossible without forcing you to reveal it either

              Unfortunately they may b

          • by Somebody Is Using My (985418) on Wednesday January 15, 2014 @09:21PM (#45971793) Homepage

            Actually, TrueCrypt already has most of those features so they don't need to be written in

            TrueCrypt 7.1a for Windows has the following options:

            AutoDismount If:
            - User Logs Off
            - Screensaver Is Activated
            - Entering Power Saver Mode*
            - Dismount if no data has been read/written in (xx) minutes

            I haven't tested ALL of them but I know the screensaver one works. Features may differ depending on platform.

            * with a warning that the Windows OS may not properly alert applications that it is shutting down due to low battery power so this feature is not entirely dependable; this seems more a limitation of the OS than the application

            And according to the Truecrypt website: "As Microsoft does not provide any appropriate API for handling hibernation and shutdown, master keys used for system encryption cannot be reliably (and are not) erased from RAM when the computer hibernates, is shut down or restarted."

            • by E-Rock (84950)

              At least for hibernation, using BitLocker on the system drive will make sure the hiberfil.sys (and I guess the paging file as well) is on an encrypted volume that can't just be copied and analyzed later.

            • by Tool Man (9826)

              The thing with hibernate is that it's capturing an image of memory, and storing on your disk. Handy when you want to wake up from really-powered-off, but also handy for anyone who wants to do a forensic analysis of everything in memory when it went to sleep. Ditto iPhone backups too IIRC, which is why (a) I don't use hibernate, and use sleep unless I'm expecting something invasive like going through US Customs where they apparently have free reign over your constitutional rights, and (b), iPhone backups are

            • Autodismount is not, of course, applicable to FDE.

        • TruCrypt can be written to automatically unmount the 'drive' as the computer goes to sleep

          It could, but it isn't. I was shocked to discover that my TC volume was still mounted after resuming from sleep. After all, notebooks get stolen, and that is why I have my passwords and SSH keys in a TrueCrypt volume. And notebooks are not normally shut down but put in sleep mode instead. So I discovered that the way Truecrypt worked made it's encryption quite irrelevant...

          I fixed the problem on my Ubuntu notebook with a "tc-unmount" script in /etc/pm/sleep.d/ but I guess not many people do that. In Windows

      • Ideally, you'd just use an OS that's secure against arbitrary programs reading out all of your RAM contents. Unforutnately Windows is not such a beast, and GNU/Linux has RAM sims mounted as a gods damned file. Unfortunately none of the mainstream OSs were designed to be secure.

        Unlike my "hobby" OS, yours do not have zero exploitable bugs, and do not employ rigorous unit tests, input fuzzing of all functions, and code coverage of every single instruction. Your OS's built in character or block device inter

    • by MidSpeck (1516577)

      Don't people burn memory blocks any more? This is sensitive data handling 101.

      I knew I should have moved to the rim of that active volcano.

  • by Midnight_Falcon (2432802) on Wednesday January 15, 2014 @07:19PM (#45970743)
    Way too tedious (and requiring physical possession of the hardware after encryption passwords/etc have been entered!) for the modern NSA -- they'll just install keylogging hardware that communicates over radio frequencies and not the internet if they need your encryption key. Then, your hacked ethernet/bluetooth port will also send them image of your drive over RF or some other discreet channel. Who needs this!?!
    • by luther349 (645380)
      they need to get a ram dump wile true crypt is running and mounted. and at the point if they can tell what is running and when aka full remote access they can use a key logger for the same effect.
  • While good to know these types of attacks exist, TrueCrypt's security model is still holding strong. http://www.truecrypt.org/docs/security-model [truecrypt.org]
    • by al0ha (1262684) on Wednesday January 15, 2014 @07:27PM (#45970803) Journal
      I wouldn't be claiming this until the audit is completed.

      http://istruecryptauditedyet.com/ [istruecryp...tedyet.com]
      • "I wouldn't be claiming this until the audit is completed."

        Why not? Nobody else has cracked it, so unless and until the audit is completed, it is indeed "holding strong".

        • by al0ha (1262684) on Wednesday January 15, 2014 @09:54PM (#45972001) Journal
          Sorry bad logic. Nobody has any idea of Truecrypt's integrity as the entire project has never been peer reviewed and nobody knows all of the persons who contribute to it, so until proven it can't be and hasn't already been compromised, nobody can be confident of its security.

          Nobody has claimed to have compromised Truecrypt, that is true, but as we know the NSA and other spook orgs would never admit it if they have and for all we know one of the anonymous developers works for a spook org.
          • It's not bad logic.

            Compare it to a new design for a physical safe. It's claimed to be too strong to crack. Now, it may be that eventually somebody will find a weakness, but until they do, the safe is still holding strong.

            There's nothing at all wrong with that. It's just a matter of what assumptions you make about what the phrase means.

            It's true that the NSA might have cracked it, but it's pointless to argue about that because it's likely that nobody else will ever know... unless of course the audit
            • Re: (Score:3, Interesting)

              by Hal_Porter (817932)

              Suppose I find a vulnerability in some software. I've got two choices

              1) Make it public and at best get a mention on slashdot when it is fixed.

              2) Sell the details to either the NSA/GCHQ etc or to criminal types. In which case no mention on slashdot, but cash up front.

              See the problem with security - any security - is that revealing vulnerabilities to the project so they can be fixed is likely to be much less lucrative than selling them other people who want to exploit them.

              If I were cynical here's what I'd do

  • by DigitAl56K (805623) on Wednesday January 15, 2014 @07:22PM (#45970767)

    Given that we're in an era of low-cost portable devices (Raspberry-Pi, BeagleBoard, etc.), it would be really nice if TrueCrypt could implement a driver that passed data off to an external, open-source device for processing that held the keys in its own memory, and provided no other service than to perform the cryptographic functions and hand back the data. It would be slower, but at least then you don't have the keys in memory on a general purpose computer running browsers, java, flash, adobe reader, etc. etc.

    Take one of those devices and attach a small screen to them and you could enter your passphrase using a keyboard attached directly to them, and use a keyfile on a flash stick plugged into the USB port too. The distro powering all of this could be minimal and audited.

    • Re: (Score:2, Funny)

      by Anonymous Coward

      And dont forget to put the RPI inside a Faradey Cage....

    • by jonwil (467024) on Wednesday January 15, 2014 @07:50PM (#45971029)

      An even better idea would be to eliminate software from the equation completly.

      Have a hardware device that contains the keys in secure storage that's on the same die as a fast hardware AES implementation (so they cant be read out by someone with full physical hardware access). Or alternately have the keys on some sort of removable storage that plugs directly into the specialized hardware (so as not to expose the keys to the host machine). The hardware would sit between the disk controller and the secure drive and basically MITM all data flowing in either direction and encrypt it as it went to the drive/decrypt it as it came from the drive).

      Done properly it would prevent a lot of attacks including the attack described in TFA.

      • You mean like the Yubikey?
        http://www.yubico.com/products/yubikey-hardware/yubikey/ [yubico.com]

        Don't forget: you can still encrypt with a keyfile you keep on a microSD card in your wallet. [copy to a USB stick in a lockbox, in case you lose it or get robbed.] Then, they can have your key, they still need the file.

      • by EETech1 (1179269)

        The key is something used constantly, can't it be kept in on die L1 or L2 cache? If it ever had to pass through RAM on the way from the HDD, just overwrite the area in RAM a few times, and leave it on the die for the whole time the computer is running.

        I''d venture to guess that keeping the key in the on CPU cache makes it an order of magnitude harder to get than keeping it in RAM.

      • by Prune (557140)

        The other issue to address is physical security. However, there have been cheap ICs for years that store a key and securely wipe it nearly instantaneously if signaled on a given pin--this allows you to hook it up to physical interlocks on a computer case, alarm system, remote control, or whatever (or OR-gate a few of those). Due to low power draw, these could easily run off a battery, preventing the security being defeated by the attacker shutting off power.

      • by tlhIngan (30335)

        Have a hardware device that contains the keys in secure storage that's on the same die as a fast hardware AES implementation (so they cant be read out by someone with full physical hardware access). Or alternately have the keys on some sort of removable storage that plugs directly into the specialized hardware (so as not to expose the keys to the host machine). The hardware would sit between the disk controller and the secure drive and basically MITM all data flowing in either direction and encrypt it as it

    • by AC-x (735297)

      Why not just use the RPi etc. as an encrypted NAS?

      • Sure, assuming you want to share your mounted volumes, you don't mind your decrypted files traveling over the network via whatever protocol your desktop OS is compatible with and its associated security model, and it handled all the underlying file systems you wanted to mount volumes on, and all the code to support mounting all those base file systems was trusted and fully audited too, and the act of running a samba server or something and all of the auth code that might go along with supporting the stack e

        • To add to this, I explicitly *do not want* the device holding my keys attached to/addressable via the network. NAS is out.

    • Why can't there be SATA controllers with drive encryption support? Your drive encryption program could then just be an expansion UEFI ROM card that prompts you for your password and sends it to the SATA controller, then erases it from main memory. There's no need to do anything else after that point, because encryption and decryption would be completely transparent to all software on the system.

      • by cfalcon (779563)

        Fuck that bro. You want to trust the private little OS that disks have running in them? If you can't audit the source code, it's crap.

        I'm sure they would implement fucking 3DES or some shit and call that secure, or a terrible version of AES that is accidentally on purpose super weak, and that's assuming they don't just cache the fucking keys.

        Hardware encryption solutions that you can buy? You have no reason to trust them.

    • Western Digital World Edition drives and some other network capable external drives run Linux. Truecrypt runs on Linux, so there's no reason you can't run Truecrypt (or cryptsetup) in your external drive.

      cryptsetup may well be included already in the default firmware.

  • The summary implies physical access is needed. But if they have remote (root) readout they could still get a ram dump and go at it, couldn't they?
  • In other words (Score:5, Insightful)

    by msobkow (48369) on Wednesday January 15, 2014 @07:39PM (#45970927) Homepage Journal

    Shut your machine OFF before you get to the border; don't put it to sleep.

    • Shut your machine OFF before you get to the border; don't put it to sleep.

      And when the spooks turn it back on, the key gets copied into RAM again because that's part of the bootup process, and necessary if the system is to read the disk and finish booting.

      In the end, it's difficult to secure something when you're handing them both the lock and the key, no matter how cunningly you've wrapped up the key.

      • by Nimey (114278)

        Only if they have probable cause to compel you to supply the password. Have you ever used Truecrypt in disk mode? You have to enter the volume password first thing after the BIOS.

        • by luther349 (645380)
          yea this has no effect in disk mode but for folder encryption etc its now broken.
        • Re:In other words (Score:5, Informative)

          by Jane Q. Public (1010737) on Wednesday January 15, 2014 @08:16PM (#45971239)

          "Only if they have probable cause to compel you to supply the password. Have you ever used Truecrypt in disk mode? You have to enter the volume password first thing after the BIOS."

          Nope. Check out the recent court cases, and past Supreme Court cases. Probable cause is NOT sufficient to compel you to turn over your password. Only a court can do that, and in order to do that legally, the court has to have a great deal more evidence than mere probable cause. In fact they have to pretty much know in advance that the drive contains material that proves you broke the law.

          Forcing someone to give up their password raises 5th Amendment questions. Pretty much the only time they can do that is if they ALREADY KNOW beyond reasonable doubt that something illegal is there, because in that case you would not be incriminating yourself; you are already "incriminated".

          • by Entropius (188861)

            Is that true also at the border?

            Specifically: if someone, US citizen or not, comes over the border with a laptop, can the border goons compel someone to boot the machine (supplying whatever passwords are necessary to do so) to enter?

            • Re:In other words (Score:4, Insightful)

              by TapeCutter (624760) on Wednesday January 15, 2014 @09:11PM (#45971717) Journal

              can the border goons compel someone to boot the machine (supplying whatever passwords are necessary to do so) to enter?

              No legal power to compel, but refusal is "suspicious behaviour" and is going to fuck up your trip until some real lawyers show up and say the court battle isn't worth the prize. Your name will go on a watch list and goons the world over will give you grief for years to come, but your porn collection will remain private.

              • Your name will go on a watch list and goons the world over will give you grief for years to come

                And if that's true, then tens of thousands of businessmen with perfectly legitimate encrypted data, who don't want to (or have any reason to) show it to government, would get put on lists and have their travels complicated or curtailed for years to come.

                That's not just intrusive, it's asinine. The government should not be interfering with business like that. It hurts everybody.

      • Re:In other words (Score:5, Informative)

        by Jane Q. Public (1010737) on Wednesday January 15, 2014 @08:10PM (#45971179)

        "And when the spooks turn it back on, the key gets copied into RAM again because that's part of the bootup process, and necessary if the system is to read the disk and finish booting."

        No, it isn't. Have you ever actually used TrueCrypt?

        When the program quits normally (or after a configurable time period), the key is GONE. It may linger in RAM for a very brief period but then it's gone. Truecrypt stores the key only in RAM, so when a machine is shut down, again the key is GONE. If your machine is on sleep or hibernate, the RAM might be preserved, but otherwise no. GP said "turn it off". Turn it off and the key is GONE.

        Booting up has zero effect on this; the key is not stored anywhere on disk (unless YOU stored it somewhere on purpose, which would be dumb).

        • by chihowa (366380) *

          Is there anything to prevent someone from tampering with the (necessarily unencrypted) bootloader (or whatever the program that accepts your password and decrypts the volume is called)? Why not replace that piece with one that logs the password or otherwise weakens the encryption? Access to the computer for 60 seconds would be sufficient to install something like this.

          This is of course relevant to any full disk encryption that doesn't have access to a TPM (and even then, can you trust the TPM?), like FileVa

          • Thats called an evil maid attack, and it is a real threat-- as is hardware keyloggers. There is mitigation, however: its not super easy to do ahead of time, because each truecrypt bootloader is unique. The drive encryption key is encrypted with the passphrase, and stored with the bootloader-- and it must be present for the "fake" bootloader to be able to decrypt the drive. So for such an attack, someone would need to have access to the drive, make a copy of the bootloader, modify the bootloader with the

        • by steelfood (895457)

          If you have a pagefile, there's a chance it could still reside in the pagefile. Do not use a pagefile if you're using truecrypt.

          There are also possible caching mechanisms behind the scenes that may also store parts of the key or the data contained in the truecrypt volume. There's nothing you can do about it, really. Best you can do is wipe your drive's free space periodically.

          But it doesn't matter. If you're a target, you're done. Your mouse, keyboard, and monitor all leak signals through the cable and user

        • by bloodhawk (813939)
          pagefile? does it have protection to ensure it is never written to the pagefile?
        • Thats not 100% true; the key generally IS stored on-disk, and is itself encrypted with your passkey.

          The reason they do this is so that you can change your passkey without re-encrpting your whole drive; instead they just have to re-encrypt your 256/512 bit key.

          For FDE, the key is stored as part of the bootloader, which is why you have to burn your own recovery disk: if the bootloader goes heels up, you need to recover it as it is the only place the actual key is stored. It also means that you can trivially

      • by luther349 (645380)
        no it will not the key will not go back into ram until its reentered by the user.
    • Shut your machine OFF before you get to the border; don't put it to sleep.

      The first question to ask is "Why you are carrying high risk/high value files across an international border?"

  • by robmv (855035) on Wednesday January 15, 2014 @07:49PM (#45971017)

    The moral of the history: if you have sensitive encrypted information on your laptop, never travel on standby mode, always turn off or use hibernation over an encrypted file or partition

  • Are they saying that it's possible for someone to read the contents of an encrypted drive if it's mounted? Wasn't this always obvious, or did I miss something?
  • by Anonymous Coward on Wednesday January 15, 2014 @07:57PM (#45971063)

    -a KEYLOGGER is an infinitely greater risk to the use of ANY encryption system, and keyloggers are trivially inserted into a PC via almost unlimited numbers of hardware and software methods.

    -gaining access to the current RAM of a system is just about the most convoluted and 'expensive' method of a targeted attack. The contents of RAM, of course, are lost once the system powers down. If you are targeted, there are a million easier ways of gaining your password. Many simply use the placement of hidden cameras. At the other extreme, remote equipment can be used to recreate your screen content via EM radiation emitted by the display and drivers.

    If Truecrypt is coded properly, it can attempt to keep the 'key' within the caches of the CPU only, and avoid 'write-back' on most processors. If RAM must be used, there are numerous obfuscating RAM usage methods that can prevent the key from living in predictable sequences of RAM bytes. However, you can assume Trucrypt is doing such as much as is useful. Truecrypt FAILS the moment the user is a LIVE (as in current Truecrypt user) target of a 1st class US intelligence operation. Gaining the password from a person who is still entering the password on a regular basis, when money is no object, and the Law is bent as is required, can be taken for granted.

    The owner's of Slashdot promote stories like this for one reason- to DISCOURAGE as many people as possible from bothering with Truecrypt in the first place. If naive sheeple THINK Truecrypt is as compromised as the NSA back-doored products from Microsoft et al, they'll 'think' they might as well use the Microsoft or similar product, because of ease of use.

    EVERY anti-Truecrypt story is NSA FUD. EVERY commercial encryption package, for instance, allows warrantless searches at the border to reveal the use of encryption, and allows the agents to strong-arm the KNOWN existing passwords from you. However, despite what the vile shills tell you here, used properly there is ZERO trace of actual encryption use on your laptop with Truecrypt, so the probability of warrantless hassle is reduced to as close to zero as you are going to get.

    • by luther349 (645380)
      i rember hearing a wile back its weakness was in the ram storage. just seems it was confirmed . as long as your encrypted stuff is not being auto mounted this attack will not work unless the machine was suspended via sleep or hibernate with the volumes still mounted or they stole a ram snapshot wile true crypt was running. as you said a keylogger will save the spooks alot of time and trouble and what they will use.
    • sheeple

      You lost me here, gunpistolman.

  • That probably counts as accesible any truecrypt volume you have in AWS and other cloud servers. Regarding your PC and laptops, there is anything in the NSA catalog [spiegel.de] targetting specifically this? They could had put it in when you bought it [theverge.com]. If well a backdoor installation could make things simpler, this hardware approach could survive OS reinstalls/replacements.
  • by Entropius (188861) on Wednesday January 15, 2014 @08:48PM (#45971537)

    It seems like the attack vector people are worried about here is "people get physical access to your machine while the key resides in RAM and extract it".

    Could you program Truecrypt to maintain a continuous watch via a laptop's built-in webcam for the physical presence of someone at the keyboard (face detection, say), and upon detecting that the person has moved, dismounts the volume, overwrites the section of memory storing keys with random bits (to protect against "put the RAM modules in the freezer" attacks), kills the bulk of the Truecrypt software, overwrites it, and then kills itself? You could add other failsafes if you wanted, I suppose (based on the machine's microphone input, perhaps), but the idea is to have a dead-man's switch that will automatically dismount the partition and remove the keys from memory when Something Goes Wrong, so the keys are only around when you are actually sitting there working, and as soon as you aren't there, they are wiped.

  • Can somebody give us some pointers about the techniques for recovering arbitrary information such as how keys, card tracks, passwords, etc from memory?

    Presumably, hostile code is injected into a running process, but once that happens, is it a brute force search? Or is something cleverer done, e.g. monkey-patching subroutines in memory, and reading fixed offsets on the stack, or indexing something off the stack into the heap?

    Memory-scraping has been in the news (mostly for the wrong reasons lately), and I'm

  • No affiliation, but this sounds like a good reason to move to TRESOR [wikipedia.org]-like implementation in which the AES key is kept in hardware registers that are cleared when you go to S3 and on each reset. It's still vulnerable to anyone that gets root access to your OS, but a cold-reboot attack or a DMA attack on the RAM are not going to work -- so that's some forward progress.

    Anyone want to take a stab at porting it to TrueCrypt?

    • by Z00L00K (682162)

      That is only one option when it comes to hiding the key. I foresee that we will have an arms race, and one alternative would be to change the key storage and keep a decoy key in the standard location just to confuse.

  • by Prune (557140) on Thursday January 16, 2014 @01:20AM (#45973159)
    If you're using TrueCrypt but without full disk encryption, encrypt your pagefile: http://www.sevenforums.com/tutorials/143662-page-file-encryption-enable-disable.html [sevenforums.com]

1: No code table for op: ++post

Working...