Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Wednesday August 05 2015, @11:37PM   Printer-friendly
from the or-they-had-the-password dept.

Discontinued on-the-fly disk encryption utility TrueCrypt was unable to keep out the FBI in the case of a US government techie who stole copies of classified military documents. How the Feds broke into the IT bod's encrypted TrueCrypt partition isn't clear.

It raises questions about the somewhat sinister situation surrounding the software team's sudden decision to stop working on the popular project last May.

US Air Force sysadmin Christopher Glenn was sent down for 10 years after stealing military documents relating to the Middle East, in addition to copying emails controlled by the commander of a special unit that conducts military operations in Central and South America and the Caribbean, as we reported.

Glenn, 34, had secret-level clearance, and worked at the Soto Cano Air Base in Honduras installing and maintaining Windows 7 systems when he swiped copies of the classified files. He was arrested, charged, and appeared before a court in the southern district of Florida, where he admitted breaking the US Espionage Act and Computer Fraud and Abuse Act. He was sentenced on Friday.

According to the Sun Sentinel , the court heard a claim by Gerald Parsons, an army counterintelligence expert, that the FBI had managed to access a concealed and encrypted hard-drive partition within which Glenn had hidden the stolen files.

The hidden compartment was protected using "a complex 30-character password," Parsons said. It would take the Feds millions of years to crack it by brute force. A summary of Parsons' testimony is here [PDF].

The court heard that the partition was created using TrueCrypt, a popular source-is-available encryption tool, developed from 2004 up until last year when its anonymous developers mysteriously closed the project down.

The TrueCrypt team's decision to cease maintenance of the project made headlines in the tech world when its website was replaced with a warning against continued use of the software, with little to no explanation of why.

[...] The encryption software that Glenn used to conceal the stolen classified materials in the Synology device is a program called TrueCrypt. In October 2011, Glenn had sent an email to an associate with an internet hyperlink to an article entitled 'FBI hackers fail to crack TrueCrypt.' In this case, the FBI did decrypt Glenn's hidden files containing the stolen classified materials.

It is, of course, entirely possible the FBI or some other agency was able to extract the password from Glenn while interrogating him – the man changed his plea to guilty halfway through the case, and may have sung like a canary. Or perhaps his computer systems were bugged, revealing his encryption key. You can read his plea bargaining here [PDF].


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1, Insightful) by Anonymous Coward on Thursday August 06 2015, @12:45AM

    by Anonymous Coward on Thursday August 06 2015, @12:45AM (#218875)

    Keyloggers. It said encrypted container, not drive. He was using Windows, without encryption, or a Linux with its shitty full disk encryption encryption that really leaves an unencrypted boot partition.

    Starting Score:    0  points
    Moderation   +1  
       Insightful=1, Total=1
    Extra 'Insightful' Modifier   0  

    Total Score:   1  
  • (Score: 5, Informative) by gnuman on Thursday August 06 2015, @01:52AM

    by gnuman (5013) on Thursday August 06 2015, @01:52AM (#218909)

    Linux with its shitty full disk encryption encryption that really leaves an unencrypted boot partition.

    So how do you expect to boot if it was encrypted? You'd need a key, which means something else would have to run to read that key, which means BIOS or similar, which would be unencrypted and we are back to square 1.

    Something has to remain unencrypted for the system to boot. It will either be a boot partition, a fake boot partition and an external R/O boot device, or some BIOS or similar. And how do you know that "they" are not monitoring your processor's data bus to retrieve your key even if your boot system is clean? There is no perfect secrecy if you don't control your hardware and you certainly do not control your hardware - you basically buy a black box from Intel or AMD or whatever entity and then *believe* you control it.

    Calling Linux's full disc crypto "shitty" is kind of poor choice of words. To me it shows you don't understand how cryptography actually works.

    • (Score: 0) by Anonymous Coward on Thursday August 06 2015, @11:31AM

      by Anonymous Coward on Thursday August 06 2015, @11:31AM (#219040)

      OpenBSD does not need an encrypted boot partition. The bootloader treats the crypto device as software raid. Once the key phrase is entered, the volume is unlocked, and the bootloader compared to a hash that was stored within the container. Pretty simple and foolproof, really.

      • (Score: 2) by romlok on Thursday August 06 2015, @12:15PM

        by romlok (1241) on Thursday August 06 2015, @12:15PM (#219047)

        Once the key phrase is entered, the volume is unlocked, and the bootloader compared to a hash that was stored within the container. Pretty simple and foolproof, really.

        Generally speaking, the time to check whether software has been tampered with is *before* you hand your secret over to it.

  • (Score: 2, Informative) by Anonymous Coward on Thursday August 06 2015, @04:05AM

    by Anonymous Coward on Thursday August 06 2015, @04:05AM (#218945)

    ...or a Linux with its shitty full disk encryption encryption that really leaves an unencrypted boot partition.

    Grub added support for encrypted boot partitions using Luks, a while ago*. So, you do not need an encrypted boot partition. Grub added support for lvm, btrfs (still eats data), etc. so even with a logical volume manager and or experimental filesystem AND on full disk encryption, you only need two sectors unencrypted for the boot loader-- and no dedicated boot partition.

    But, in addition to being wrong, your comment is silly since, if you are not booting from alt media, you will always have something unencrypted on the disk, or it will be impossible to boot.

    And, you could *always* boot from alt media with luks (or bare dmcrypt).

    *Grub luks support is kinda a pita to use, though. You can only enter your passphrase once, if you mess up you have to reboot. And, you have to enter your passphrase again when linux boots, there is no mechanism to pass the credential from boot loader to kernel. You also loose the ability to unlock your hard drive at boot from a remote location (this is one really nice feature of a "shitty" dedicated unencrypted boot partition; debian even has a package that will set it all up for you. You can ssh into the box in a half booted state, and unlock the disk with the root partition, then the box continues to boot).

  • (Score: 0) by Anonymous Coward on Thursday August 06 2015, @11:55AM

    by Anonymous Coward on Thursday August 06 2015, @11:55AM (#219044)

    or a Linux with its shitty full disk encryption encryption that really leaves an unencrypted boot partition.

    Bitlockered Windows with TPM also has an unencrypted boot partition.