Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Friday May 30 2014, @08:45PM   Printer-friendly
from the some-settling-of-contents-may-have-occurred dept.

According to a German researcher, Mattias Schlenker, we are to expect that the reason for TrueCrypt's recent shutdown is not a National Security Letter, but a serious security flaw in how TC container files are created on Windows.

He expects the flaw to become public within a week.

What gives this chap some credibility is that he's one of the developers of "desinfec't", a Knoppix-based live Linux that comes with several virus scanners and is distributed by well-renowned German computer magazine c't (whose mother company/publishing house, Heise, hosts the forum where he made his announcement).

Link to his original German posting: http://www.heise.de/security/news/foren/S-Re-Warum -TrueCrypt-nicht-in-Desinfec-t-enthalten-ist/forum -280432/msg-25289876/read/

See our earlier coverage: TrueCrypt Discontinued, Compromised.

 
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: 2) by Angry Jesus on Friday May 30 2014, @11:46PM

    by Angry Jesus (182) on Friday May 30 2014, @11:46PM (#49357)

    > if the image is not mounted when the attacker wants to gain access, it doesn't matter what OS it's on.

    It is possible that what matters is the OS that created the image. Off the top of my head I can think of at least one OS-specific vulnerability - the random number generator (RNG). If the RNG that truecrypt uses is OS-specific (as in it uses an OS-provided system call to generate random numbers) then it would be plausible that containers created on just one OS are vulnerable while others are not.

    Truecrypt might uses its own RNG, I don't know. I'm just pointing out a way that the OS might make a difference.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by edIII on Saturday May 31 2014, @12:52AM

    by edIII (791) on Saturday May 31 2014, @12:52AM (#49373)

    You would think that TrueCrypt would use whatever CSPRNG (Cryptographically-Secure-Pseudo-RNG) is available in the Windows cryptographic primitives, but it doesn't.

    Very difficult to find any documentation because TrueCrypt not only crippled the encryption mode, but also removed all documentation of the RNG from their website (interpret that as you may)

    I was able to find an audit paper [privacy-cd.org] that detailed the proprietary RNG used by TrueCrypt to some extent:


    The Random Number Generator of TrueCrypt

    As any other good encryption program TrueCrypt needs random numbers. In the case of TrueCrypt these are 64 bytes of “salt†used to derive the key for the header encryption from the password. Then it needs between 32 and 96 bytes for the master key by which the volume is encrypted. Another 32 to 96 bytes are needed for the XTS key used in the XTS encryption mode. The size of these keys depends on the number of ciphers of the selected encryption algorithm. Besides this TrueCrypt also fills the volume with random data as is explained in the previous section. To create all these random data is the task of the random number generator which TrueCrypt implements. The random number generator of TrueCrypt is based on a paper written by Peter Gutmann in 1998(9). It makes use of mouse positions and times of events like mouse clicks or keyboard entries. These data are practically unpredictable. On a Linux system random values from the pseudo devices /dev/random and /dev/urandom are added to these data. To date there are no known attacks against this random number generator. But a paper by Kelsey, Schneier, Wagner and Hall(10) where similar though simpler pseudo-random number generators were analyzed evinces that such an attack may be possible if an attacker could actively interfere on the system while random numbers are being generated. An inference from this analysis was the development of Yarrow which is definitely a better pseudo-random number generator(11)
    .
    An active attacker with root privileges may also eliminate the randomness from the Linux random devices by the commands
    sudo rm /dev/random /dev/urandom
    sudo mknod /dev/random c 1 5
    sudo mknod /dev/urandom c 1 5
    completely12

    As similarly argued above this is not an objection against the use of these devices by TrueCrypt but minds us that TrueCrypt must only be used in a secure environment. The implementation of the random number generator in TrueCrypt has the disadvantage that there is no estimate on the amount of real randomness gathered. That's why it doesn't block until the mouse has been sufficiently moved or sufficient other random events happened. This corresponds
    to the behavior of the device /dev/urandom on Linux in contrast to /dev/random. By this behavior the user isn't troubled with the need of lengthy mouse movements but then he is less secure. We recommend to move the mouse for at least one minute before clicking the “Format†button on container creation. We also recommend to uncheck the check box for “Show†in this dialog. Otherwise 13 bytes of the current random pool are permanently displayed. Afterwards even
    the first 13 bytes of the header and the master key are displayed. As this could be intercepted by an attacker for example with a receiver for the monitor radiation unchecking this check box is a security demand.

    9 See Peter Gutmann, “Software Generation of Practically Strong Random Numbersâ€, Usenix Security Symposium 1998
    10 John Kelsey, Bruce Schneier, David Wagner and Chris Hall, “Cryptanalytic Attacks on Pseudorandom Number Generatorsâ€, 1998

    However, this is just key generation. Typical usage on a full volume encryption would absolutely have to use the cryptographic primitives found in the OS to provide the performance required. There is simply no way that TrueCrypt could gain enough entropy from the mouse alone.

    Personally, I always found it somewhat suspicious that TrueCrypt refused to use the CSPRNGs available in modern cryptographic primitives... but then again... the NSA did an extremely good job of compromising the Dual Elliptic Curve Deterministic Random Bit Generator (Dual_EC_DRBG) [wikipedia.org], so their paranoia was not unfounded.

    In any case, the CSPRNGs in cryptographic primitives on both Windows and Linux already make use of many non-deterministic activities within the OS and inputs (need a citation myself) that provide truly random numbers to /Random, which is where (IIRC) that /URandom gets its input to provide much larger amounts of random numbers needed to meet the demands of typical usage.

    Considering that you have to trust your OS anyways (otherwise no reason to be running it or TrueCrypt) it doesn't make a whole heck of a lot of sense to create your own in that way. If they wished to use something different, then they should have proposed a new CSPRNG that could be included in the standard primitives.

    It's a real fucked deal anyways since the NSA has practically committed a "scorched earth" tactic by leaving the entire world with zero confidence whatsoever in either the approval process for the NIST standards, or the current CSPRNGs that are there anyways.

    So in the end, getting TRNG input directly from a source like a mouse to generate the key at least wasn't that crazy. It just could've been implemented a little better, and should have collected the same TRNG data that standard cryptographic primitives do, and then applied it's own CSPRNG to gain more volume if required.

    • (Score: 2) by frojack on Saturday May 31 2014, @01:44AM

      by frojack (1554) on Saturday May 31 2014, @01:44AM (#49390) Journal

      However, this is just key generation. Typical usage on a full volume encryption would absolutely have to use the cryptographic primitives found in the OS to provide the performance required. ...
      Personally, I always found it somewhat suspicious that TrueCrypt refused to use the CSPRNGs available in modern cryptographic primitives.

      I suppose it is precisely because the encryption primitives on windows is suspected to be hopelessly compromised that they went their own way on this.

      If the machine was not compromised at the time these containers were created, it should remain uncompromised. So unless the truecrypt people suddenly found out there is a master key in Microsoft's encryption, I still see no reason for them to suddenly walk away from their product in despair. They could just fix their problem, apologize, and move on.

      --
      No, you are mistaken. I've always had this sig.
      • (Score: 2) by edIII on Saturday May 31 2014, @02:52AM

        by edIII (791) on Saturday May 31 2014, @02:52AM (#49414)

        I agree about them fixing the problem and moving on, which is why I'm so troubled that they haven't made a full disclosure about what happened. The silence is deafening over there.

        Without tearing apart the code myself, which is no longer available anyways, I strongly suspect that TrueCrypt *was* using a CSPRNG from the standard primitives, despite evidence to the contrary. It's not like we have access to documentation anymore; It's been removed.

        If the machine was not compromised at the time these containers were created, it should remain uncompromised.

        I'm not sure that is true, and I'm pretty positive that's it not. Unless you are mounting a container as read only.

        Key generation is only one activity related to initialization of a container. During normal use on a container TrueCrypt needs to provide itself with large amounts of random numbers. This is especially true if you are using Blowfish as one of the chained algorithms.

        Moreover, during container creation that requires an incredibly large amount of high entropy random numbers to initialize the container. How could they achieve such volume both during key creation and container operations? TRNGs are wholly incapable of doing so without expensive dedicated equipment to provide it. Commodity hardware has no choice but to rely on CSPRNGs for the volume required in modern encryption use cases. So my gut tells me that they were in fact using the standard primitives.

        Another checkmark in favor of TrueCrypt is that it has survived all kinds of attacks previously in the known literature. I heard rumors that some people claimed they could detect hidden containers, but no actual papers, citations, or proof of concepts. I've not heard one single court case where the government had defeated plausible deniability of the hidden container.

        What changed? I suspect that TrueCrypt containers are at risk regardless of when or if the machine was compromised. I just don't know how.

        --
        Technically, lunchtime is at any moment. It's just a wave function.
        • (Score: 1) by fnj on Saturday May 31 2014, @06:38AM

          by fnj (1654) on Saturday May 31 2014, @06:38AM (#49471)

          ...code myself, which is no longer available...

          The source is still available. Everyone who ever downloaded it potentially has kept a copy. If you really want to reference it, it is no trick at all to find a copy.

      • (Score: 2) by dbot on Saturday May 31 2014, @12:03PM

        by dbot (1811) on Saturday May 31 2014, @12:03PM (#49537) Journal

        I suppose it is precisely because the encryption primitives on windows is suspected to be hopelessly compromised that they went their own way on this.

        Windows can't do it, so let's take our pid, and gettimeofday() and seed rand()? [6]

        Both linux[1] and Windows Vista (onward)[2] are using fortuna[3], for their RNG. RNGs in Windows prior to Vista were vulnerable[4]. XP SP3 received a patch[5].

        Even if you want to roll your own RNG, /which is a really, really bad idea/, you should at least XOR your stream with your OS's RNG. The resultant stream will be as random as the most random source, providing there is no correlation between the two sources (which itself would be hard to prove). You can see this if you take any stream and XOR it with {1}, {0}, or {01}. Using a predictable sequence does not affect the randomness of the stream.

        1. https://www.schneier.com/blog/archives/2013/10/ins ecurities_in.html [schneier.com]
        2. http://eprint.iacr.org/2014/167 [iacr.org] (pp3 in abstract)
        3. http://en.wikipedia.org/wiki/Fortuna_(PRNG) [wikipedia.org]
        4. http://en.wikipedia.org/wiki/Random_number_generat or_attack#Windows_implementation [wikipedia.org]
        5. http://www.computerworld.com/action/article.do?com mand=viewArticleBasic&articleId=9048438 [computerworld.com]
        6. http://opensslrampage.org/post/82975103611/so-the- openssl-codebase-does-get-the-time-add-it [opensslrampage.org]

    • (Score: 2) by maxwell demon on Saturday May 31 2014, @10:30AM

      by maxwell demon (1608) on Saturday May 31 2014, @10:30AM (#49520) Journal

      (Taking the liberty to remove stray characters from the quote and add proper formatting):

      An active attacker with root privileges may also eliminate the randomness from the Linux random devices by the commands

      sudo rm /dev/random /dev/urandom
      sudo mknod /dev/random c 1 5
      sudo mknod /dev/urandom c 1 5

      completely

      I wonder if that would still work with udev. But nevertheless, it's an interesting point; it means that before using /dev/random or /dev/urandom you should first make sure that they have the correct major and minor device number.

      --
      The Tao of math: The numbers you can count are not the real numbers.
  • (Score: 2) by Tork on Saturday May 31 2014, @04:11AM

    by Tork (3914) Subscriber Badge on Saturday May 31 2014, @04:11AM (#49439)
    I apologize for my ignorance, but isn't the step where you move the mouse around for a while designed the seed the random number generator, thus keeping it disconnected from whatever the OS and/or CPU thinks is random?
    --
    🏳️‍🌈 Proud Ally 🏳️‍🌈
    • (Score: 2) by Angry Jesus on Saturday May 31 2014, @05:32AM

      by Angry Jesus (182) on Saturday May 31 2014, @05:32AM (#49459)

      To over-simplfy: A good seed is just a starting point (that's why its called a seed). For any generator, if you start with the same seed you'll get the same list of pseudo-random numbers out of it. If the generator's algorithms are weak or somehow flawed, then even a purely random seed won't be enough to guarantee that the list of "random" numbers really is random.

      Here's an explanation of how a deliberately weakened random number generator can be exploited, you don't really have to follow anything but the most basic math in the explanation to see how the end result is compromised.

      http://numberworld.blogspot.com/2013/09/nsas-sp800 -90-dual-ec-prng.html [blogspot.com]

      • (Score: 2) by Tork on Saturday May 31 2014, @11:08PM

        by Tork (3914) Subscriber Badge on Saturday May 31 2014, @11:08PM (#49729)
        Although I'd admit to the topic being extremely fuzzy to me... I think I get what your link is saying, at least in a crude-Commander-Riker-sorta-way.

        I appreciate it, thank you.
        --
        🏳️‍🌈 Proud Ally 🏳️‍🌈