Forgot your password?
typodupeerror
Security

Solution Against Cold Boot Attack In the Making 260

Posted by kdawson
from the warm-it-by-the-fire dept.
Bubba writes "I just discovered this blog: Frozen Cache. It describes a concept for preventing cold boot attacks by saving the encryption key in the CPU cache. It is claimed that by disabling the CPU cache the key will remain in cache and won't be written to memory. The blog says they're working on a proof-of-concept implementation for Linux. Could this really turn out to be a working solution?" Update: 01/19 20:26 GMT by KD : Jacob Appelbaum, one of the authors of the cold boot attack paper, wrote in with this comment: "It's not a solution. It simply seeks to make it more obscure but an attacker would certainly still be able to pull off the attack. From what is on that blog, there's still a full keyschedule in memory at this time. This is how we reconstruct the key, the redundant information in memory; it's not just the 128/256 bit key itself. For older methods, they needed the actual specific key bits but we don't need them because we recreate them. Basically, the CPU is acting as a ghetto crypto co-processer. Emphasis on ghetto. It's a nice suggestion but the devil is in the details and sadly the details in this case aren't really up to snuff. It's a bogus solution."
This discussion has been archived. No new comments can be posted.

Solution Against Cold Boot Attack In the Making

Comments Filter:
  • Freeze the CPU (Score:5, Insightful)

    by despe666 (802244) on Sunday January 18, 2009 @07:15PM (#26510439)
    Good idea, until they figure out how to cold boot the CPU as well.
    • Re:Freeze the CPU (Score:4, Interesting)

      by RiotingPacifist (1228016) on Sunday January 18, 2009 @07:31PM (#26510567)

      why are you modded funny? is there any reason that the cpu memory cannot be attacked in a similar way to standard memory? The hardware you need to pull it off is probably a bit more obscure but is there a reason that you cant stick a cold CPU in a multicpu board and read its memory from a second CPU?

      • Re:Freeze the CPU (Score:5, Informative)

        by Anonymous Coward on Sunday January 18, 2009 @08:20PM (#26510959)

        You need to understand that there are different types of RAM. The main memory, that of which you have gigabytes, is DRAM. CPU caches are SRAM.
        DRAM is, essentially, a tiny capacitor that is regularly recharged. If you cool it down, it doesn't lose its charge as fast, so you can read it even after power loss.
        SRAM works differently. The data is stored by a few transistors wired together in a way so they can maintain a specific set state even when the external input goes away. There are no capacitors involved here, so once the supply voltage drops, the data is lost.

        • Re:Freeze the CPU (Score:5, Informative)

          by SlashWombat (1227578) on Sunday January 18, 2009 @09:50PM (#26511599)
          Carefully repowering SRAM can maintain the contents. I have seen SRAM come up with essentially 99% of the contents still intact after the SRAM had been powered down for over a week. I guess that once powered up, the SRAM has a preference to come back the way it was before powerdown.

          Or perhaps the slight residual voltage kept the SRAM contents intact. (Even though it was probably less than one tenth of a volt.) SRAM draws very little current when the voltages are reduced. Thus the power rails can maintain some small voltage for a very long time. .
          • Re: (Score:3, Insightful)

            by learningtree (1117339)

            Carefully repowering SRAM can maintain the contents. I have seen SRAM come up with essentially 99% of the contents still intact after the SRAM had been powered down for over a week. I guess that once powered up, the SRAM has a preference to come back the way it was before powerdown. Or perhaps the slight residual voltage kept the SRAM contents intact. (Even though it was probably less than one tenth of a volt.) SRAM draws very little current when the voltages are reduced. Thus the power rails can maintain some small voltage for a very long time. .

            I would really like to see any citation to support your point. If true, this is really an interesting concept.

        • Re: (Score:3, Informative)

          Transistors, especially MOSFETs are quite capacitive by nature of functioning by P-N junctions. MOSFETS have fairly considerable gate capacitance due to the fact that the gate is insulated by a layer of gate oxide, forming a quite apparent capacitor. This is indeed why your computer has a clock speed limit, it takes time to charge up these capacitors due to an RC time constant.
      • Re:Freeze the CPU (Score:5, Interesting)

        by bperkins (12056) on Sunday January 18, 2009 @08:25PM (#26510997) Homepage Journal

        Most cache is implemented as a flop, which loses its state on power down almost immediately. I don't think it's possible.

        • i thought CPU caches were mostly implemented through SRAM, which does possess a certain level of data remanence.

          otherwise, there's always rubber-hose cryptanalysis [wikipedia.org].

          • by bperkins (12056)

            An SRAM cell is typically a cross coupled inverter (from what I've seen). There's not much potential for memory there. When the power supply reaches zero, the bit is gone.

            With DRAM that's not quite the case, which is why the cold boot attack works. Even though the power supply is zero, the bit is still there on the cap.

      • Different kind of memory. Normal memory, DRAM, is more or less a capacitor and a transistor. You store the charge for the state in the capacitor. So that's the idea as to how you can get at it later. While they do discharge when power isn't applied, it is not linear, so some residual charge can still be picked up. Cache memory is SRAM. That's a combination of six (or more in some cases) transistors, no capacitor. So when power dies, there isn't any residual charge left.

        Not saying that maybe something couldn

        • The only thing with SRAM is that when its powered on it'll flip to one of its states and supposedly (Ive never tested this out myself) it will be biased to the state it had when it was powered off. Of course the effect that causes this bias is so small that any fluctuation will get rid of it and leave you with random data. I figure the simplest way to be sure is too simply add a bit of logic to the CPU initialization that wipes the caches the moment power is applied.

    • Re:Freeze the CPU (Score:5, Interesting)

      by msgmonkey (599753) on Sunday January 18, 2009 @07:35PM (#26510603)

      Although marked as Funny, you could quite easily open the PC take out the BIOS ROM whilst the machine is running (the BIOS is shadowed in normal operation), stick a new custom one in that probes the cache and do a hard reset.

      • Re:Freeze the CPU (Score:4, Interesting)

        by msgmonkey (599753) on Sunday January 18, 2009 @07:38PM (#26510639)

        Additionally this could also be used to get a near perfect dump of RAM too.

        • Re:Freeze the CPU (Score:5, Insightful)

          by ion.simon.c (1183967) on Sunday January 18, 2009 @09:12PM (#26511309)

          Thus, if the attacker has physical access to your box, you're screwed!

          • by Alsee (515537)

            if the attacker has physical access to your box, you're screwed!

            Yeah... especially if you're the RIAA/MPAA and the "attacker" is the owner having physical access to his own box.

            I love these stories on physical-access attacks. They are great techniques for an owner to get around hostile Trusted Computing on his own computer. Cold-boot or warm-boot your own computer and read your data and your keys out of your RAM, even when Trusted Computing tries to deny you this sort of access to your own keys and data.

            -

            • Re:Freeze the CPU (Score:4, Informative)

              by Zan Lynx (87672) on Sunday January 18, 2009 @10:47PM (#26512027) Homepage

              Except that real "trusted computing" using a TPM chip doesn't store the key in the CPU or in RAM, it is stored in the TPM.

              • Re: (Score:3, Informative)

                by Sven Tuerpe (265795)

                Except that real "trusted computing" using a TPM chip doesn't store the key in the CPU or in RAM, it is stored in the TPM.

                This is a dangerous belief. It is true that some keys remain inside the TPM, at least as long as the chip is being accessed only through its wire interface. However, the TPM ist not suitable for bulk encryption. Applications therefore typically use the TPM only to store keys, which are extracted to memory when needed.

              • Re: (Score:3, Interesting)

                by Alsee (515537)

                Trusted Computing is built on an entire tree of keys. You're right that the master pair of keys (PrivEK and RSK) never leave the chip. You're right that reading RAM will not give you a simple full crack of the Trust system on your computer. However by reading RAM you can snatch the lower levels keys peicemeal, and you can read out decrypted files piecemeal. For example you play some DRM music and do a RAM grab. If you're lucky that RAM grab will give you the key to decrypt all of the DRM music files on your

      • by w0mprat (1317953)
        Why bother dropping in a custom BIOS chip? Many mainboard bioses can be flashed via software from within a running operating system. Once you've written to the ROM you then need your code to force a reboot. On the next boot your bios code runs with disabled cache and does the cache dump. (Heck RAM too while you're at it). Interestingly the original bios could be restored leaving the machine functional.

        I imagine what prevents this kind of attack being useful is the limitation to a specific make and mode
        • by cnettel (836611)

          http://en.wikipedia.org/wiki/CIH

          Note, though, that some (all?) motherboards these days tend to have a tiny region that's either ROM or not normally flashed for recovery if the checksum doesn't match up. You might need to flash that as well, or just go along fooling it with a proper checksum (I don't think they employ any real signing.)

  • Great! (Score:5, Funny)

    by Anonymous Coward on Sunday January 18, 2009 @07:22PM (#26510481)
    Man I've been waiting for this! Lately the risk of a cold boot attack has really scared me, it's to the point where I don't even turn my computer on anymore!
  • According to the blog, the Proof of Concept would work on "most" x86 architectures.

    To someone who knows more about the down-and-dirties: will this approach work on non-X86 systems?
    • by Improv (2467)

      It depends on the architecture, of course.

    • Re: (Score:3, Interesting)

      by LiENUS (207736)
      The Hitachi Super-H 4 processor (used in the Dreamcast among other things but I believe now as dead as the Dreamcast is). Supported a mode where you could disable half of the cache and use it as general purpose RAM.
      • Re: (Score:3, Interesting)

        by ishobo (160209)

        It is still alive, with its sibling the SH-5, for the embedded market. Its core is licensed in the same way as ARM and MIPS.

    • Depends. It wouldn't work on any architecture that doesn't do caching, of course. Don't know that there are any of those, but if there are, well then they are out. Also won't work on any architecture that you can't control the caching on. If it always caches memory and you can't mess with how, the trick won't work. I would guess it would work on most architectures out there, but I don't know.

  • a hack on a hack (Score:4, Insightful)

    by freddy_dreddy (1321567) on Sunday January 18, 2009 @07:28PM (#26510545)
    FTA: "Disabling/freezing" the CPU's cache severely degrades the performance. However, this seems acceptable if one considers that this special mode only needs to be set whenever the screen is locked (all efforts are pretty much worthless if an unlocked laptop is stolen).
    br/>Sounds like a tiny back door fix with a hell of a cat flap in it.
    • by mrmeval (662166)

      If the laptop is unlocked you just copy the drive to some other device. That's been the gaping hole in every OS back to the abacus.

      If you want to fix that have some sort of longer range proximity card that locks or otherwise shuts off access when the user is not present.

      Considering that most /.ers mold their butts to a chair put a switch in it to detect said butt.

    • by kmahan (80459)

      Why not just store it in a couple of locked cache lines?

  • by Zergwyn (514693) on Sunday January 18, 2009 @07:32PM (#26510579)

    Or the converse, I suppose (hardware solutions can add another layer to this). This looks like some very interesting work, and may have more applicability in general beyond this one scenario. I'm certainly looking forward to following their implementation as it comes along. But with that said, if this attack was a serious concern for a given entity there seem to be some obvious potential hardware solutions. The attack essentially depends on being able to shutdown the computer but keep the memory cold enough that the randomization time is slowed down tremendously, giving enough time to perform a dump of the contents onto another system for further analysis. Therefore, it can be prevented by, for example, having electric heater units surrounding the memory connected to a dedicated capacitor bank and temperature sensor, as well as a sensor to detect if someone tries for force open the machine (intrusion alarm). Then the system can perform a scram shutdown (or if it is just shutdown normally), and the heaters can assure that the memory is kept hot for a couple of seconds afterwards even in the face of attempted cooling. It only needs to manage it very briefly and then all the contents are scrambled. Other similar methods (maybe a really micro EMP inside a shield memory space) would be possible to, but basically they just need to deny an attacker for a very short amount of time or ensure entropy in the RAM and then the attack is useless.

    Ultimately a dedicated hardware secure key store would be better and easier to integrate across all systems, and this more software solution of course has the massive advantage of being able to run for free on existing hardware. But the above could at least be retrofitted on nearly anything, and while it is more esoteric, then again so is the attack since it requires physical access.

    • Good idea. If we can get the manufacturer promises there aren't any government backdoors, we'll be perfectly safe from any and all conceivable attacks.

      But I guess it is an improvement at least.

    • by RAMMS+EIN (578166)

      Actually, scrambling the whole RAM sounds like a good idea. The encryption key is probably not the only thing you want to keep a secret.

    • I thought Slashdot was against the TPM chip? Last I read, it was supposed to be used for anti-piracy.

      http://en.wikipedia.org/wiki/Trusted_Platform_Module [wikipedia.org]

      • by Alsee (515537)

        I thought Slashdot was against the TPM chip?

        The Slashdot community is made up of varied views on everything, but yes the majority here do object to the TPM.

        That said, the grandparent post did not mention the TPM. He described some features similar to the TPM, but that's kinda like saying a home security system is similar to a prison security system. Both might have bars on the windows, but they are fundamentally different designs. Designing a security system to protect and benefit the person living there (a

    • I would (if I were seriously worried about this sort of thing), do something like the following for a desktop unit:

      1) Get a thick case that can be locked.

      2) Get a "giant fuck-off padlock".

      3) Apply #2 to #3.

      4) Place the case somewhere somewhat distant from monitor and input devices. Ensure that case is in location that is very inconvenient to access.

      5) Wire up phase lines of the power supply directly to the RAM sockets, controllable by a switch. Also add a killswitch that cuts all power to the inside of th

  • by Kindaian (577374) on Sunday January 18, 2009 @07:37PM (#26510631) Homepage

    Wasn't the "secure computing" preached by Intel/MS and others a "secure" platform that would solve all the security issues?

    To me seams that it was only a farse to disguise DRM into everyones computers...

    And fail...

    • This was really just a marketiung exercise with just enough technical mumbo-jumbo to make it sound real.

      If you consider that the primary goal was really to make people *think* that they were doing something useful, then , yes, the exercise was successful.

    • I think any security offered by TPM would be against remote exploits. The mantra I keep hearing is "all bets are off once an attacker has physical access" which makes sense.
    • The "secure computing" preached by MS does not protect against OS bugs, buffer overflows, or any of the myriad local or remote attacks based on software flaws. The only "security" it offers is a way to prevent end users from downloading and installing the software of their choice. I don't mean to minimize the value of this - it is an important base to cover. The "typical" Windows user sees a free screen saver and goes "Ooh! Shiny!" and installs it - thereby joining yet another botnet. When/if Linux reac

    • Wasn't the "secure computing" preached by Intel/MS and others a "secure" platform that would solve all the security issues?

      No

      To me seams that it was only a farse to disguise DRM into everyones computers...

      And fail...

      No again. Here is some useful information [ibm.com] on this from IBM.

      • Then explain why I cant have my private key to the TPM I may own?

        Or, who knows the proper private key to unlock any TPM?

  • A safer alternative (Score:4, Interesting)

    by kasperd (592156) on Sunday January 18, 2009 @07:48PM (#26510733) Homepage Journal
    This is supposed to protect the key while the system is locked, and a password is used to unlock the screen. But if a password is required to unlock anyway, the key doesn't even have to be accessible while the system is locked, the password itself could be used to decrypt the key while unlocking. Of course there is a drawback in that any disk operations would have to be delayed until the system is unlocked, that might not be acceptable for all users.

    The simplest way to implement my proposal would probably be to suspend the system instead of just locking the screen (like you do if you are not going to be using your laptop for a few hours). It just has to be implemented correctly such that the key really isn't available until decrypted using the password that you enter when waking it up.

    If you want to lock your laptop and leave it doing things in the background requiring disk access, then the idea from this article might be valuable. There are other possibilities, one alternative is to store the key in special cryptographic hardware from where it can't just be read out (I haven't thought through the details of such a design, there are obviously some hurdles that would need to be sorted out). Or you could make some use of asymmetric cryptography, I don't think any storage encryption currently does that, since it could have a performance penalty, but it would provide some protection against attacks like this. You could also use ciphers that are less vulnerable to this kind of attack. Part of the attack is to use the key schedule as a kind of error correcting encoding that will help recovering the key. Key schedules are typically designed with performance in mind, and this kind of attack is not considered. But for most storage encryptions the performance of the key schedule isn't important, so a different key schedule could be designed to have no error correcting properties. (I think that just means the function mapping from key to key schedule would have to be a PRNG).
    • by Chaos Incarnate (772793) on Sunday January 18, 2009 @08:13PM (#26510907) Homepage
      The problem with encrypting the key via password is that it requires either storing the password in a reversible fashion (not hashed), which is terrible security, or requiring the user to enter the password before locking the system, which prevents inactivity timers from locking the system.
      • Public-key encryption would resolve that issue. Only the decryption key need be protected by a passphrase; encryption can take place non-interactively via the public key.

      • by blueg3 (192743)

        Or preparing the password-encrypted key when the password is used to log in. It seems fairly uncommon these days to have a screen-unlock password that is not the login password.

  • ... so the solution to a cold boot attack is make your computer so damned slow that you don't want to use it. Therefore you won't want to create encrypted volumes to store your world domination plans anymore.

    • Hey, my Harry Potter/X-Men/Buffy the Vampire slayer crossover fan fiction is going to make me millions and I need to protect it.
    • The scenario is that someone steals a running, but locked laptop, and wants to read your encryption keys stored in RAM. If it's not running, then the encryption keys aren't in RAM. If it's not locked, then you're SOL anyway.

      So the idea is to move the keys out of RAM and into the cache temporarily while the machine is locked. When you log back in, the cache gets re-enabled so you won't notice any difference in performance.

      • Re: (Score:3, Interesting)

        The scenario is that someone steals a running, but locked laptop

        Let's assume a REAL scenario. The real scenario is not everyone runs Windows and not everyone runs laptops, and not everyone uses X86 architecture. Just because the screen is locked doesn't mean the encrypted volume is not in use. Come to think of it, Windows + Laptop + Locked doesn't even mean it's not in use. The cold boot attack is also more useful against desktop machines because it's much easier to freeze up the memory good because you usually have unrestricted access to most of its surface area.

        E

        • Just because the screen is locked doesn't mean the encrypted volume is not in use.

          It will if you want to use access highly sensitive information on that machine.

          The cold boot attack is also more useful against desktop machines because it's much easier to freeze up the memory good because you usually have unrestricted access to most of its surface area.

          Desktop machines are typically covered by site security. Traveling diplomats, CEOs, dissidents, etc. want to be able to access their sensitive data in situations where they don't completely control site security. This gives them some additional protection if implemented with secure user practices (i.e. locking your workstation whenever you are not present).

          I leave my computer calculating possible attack vectors for that exhaust port and lock the screen while I go make a coffee; it's going to take a couple of hours to compute, you see.

          You do that on a separate server under physical lockdown. Obviously this o

          • secure user practices

            You do that on a separate server under physical lockdown

            Are you so naive to assume that the user will actually follow secure practice all of the time?

            Are you so naive to believe that physical lockdown will save you from an invasion by the feds/rival drug dealers/etc?

  • so how often are these cold boot attacks actually performed in a hostile situation (as opposed to under controled conditions for demonstration, or to legitimately recover lost passwords or whatever)
  • zero on power up? (Score:2, Interesting)

    by Eil (82413)

    This sounds like quite an over-complicated solution. Isn't it possible to design "secure" memory chips that zero their contents when power is first applied? I mean, memory chips are pretty "dumb" (from a design logic perspective, which is why cold-boot attacks work) so how hard would it really be to add this function to the chip? If it significantly adds to the manufacturing cost, sell it as a feature. I know of many agencies and individuals who would be interested in memory that's secure against cold-boot

    • by Zironic (1112127)

      How exactly would a memory chip define "power first applied"? And how would the memory itself erase anything?

      Afaik RAM is just a bunch of cells that are either charged or they're not and it's all decided by the memory controller.

      • Re: (Score:2, Funny)

        by Anonymous Coward

        How exactly would a memory chip define "power first applied"? And how would the memory itself erase anything?

        Well, I might be taking a stab in the dark here, but perhaps it has something to do with THE ADDITIONAL CIRCUITRY proposed by the Parent?

        Nothing ever gets done in the world anymore because those of us with an understanding of our surroundings are too busy facepalming ourselves constantly.

      • How exactly would a memory chip define "power first applied"?

        How exactly would we integrate color into a tv set?

        How exactly would we go to the moon?

      • Memory chips contain a lot more logic than you think they do. For starters, the miniscule charge stored in the capacitors has trouble getting through a microscopic bitline in the DRAM chip, so there's no way it would make it out to a chip pin much less the memory controller - that's why DRAM has highly sensitive differential amplifiers (one for each bitline pair). Modern DRAM uses relatively interesting interfaces that, while still closely related to the actual operations needed to read out the charge in th

  • Cold boot attacks on laptops are interesting and all, but me, I'd just use the firewire port [hermann-uwe.de]

    It is applicable on a smaller number of laptops, but you also have write access and the machine continues running (less suspicious). Somewhere (perhaps in my link, can't remember) I saw a nifty python script that patches winlogon to allow unlock by entering an incorrect password. If you're an exceptionally slick bastard, you might squeeze a keylogger/downloader/etc into some dark corner of RAM and hijack some unlucky

  • That's why I set my thermometer to 30 C and leave it on all day.

  • In many cases, all you need is the right Firewire device [wikipedia.org] to scan memory, for one thing.

    The other is that saving the keys in the register file doesn't help much if context switches can still happen. Guess where the keys get saved on a context switch? RAM, naturally. And don't forget paging behavior--although if the page holding the keys was allocated within the kernel with kmalloc(), you're ok there.

    If I were going to try to brute-force a key based on a chilled RAM, I'd just dump the entire contents of RA

  • by Terje Mathisen (128806) on Monday January 19, 2009 @02:52AM (#26513357)

    In the day of multi-core everywhere, a possible solution seems to be:

    Dedicate one core to handle both screen unlock and disk encryption, but only when locking the machine.

    On this core I would use one (128 bit) or two (256 bit) SSE registers to hold the disk key, and another register to hold the unlock credentials, then setup a static communication area where the other core(s) can leave messages, in particular an attempt to unlock the machine.

    The dedicated lock core would stay in a loop, comparing the content with the unlock creds (i.e. hashed/salted password) and write the disk key back to memory upon receipt of a valid entry.

    Using this approach means that you don't need to mess around with MTRRs or other cache control instructions, you just need to schedule everything else onto the other core(s), including all interrupts (which would (lazily?) writeback SSE register content on a task switch).

    OTOH, there are of course some obvious downsides to this approach as well, in particular the fact that the locked core cannot go into a regular sleep mode, if said mode requires an interrupt to get back out of. :-(

    Terje

  • As long as (most) disk activity can be stopped while the screen is locked, there is a solution which is both easy and safe:

    The disk key in any reasonable full disk encryption setup is stored in encrypted form, meaning that the disk password is required to decrypt/retrieve it, right?

    So what's stopping us from "simply" freezing all disk activity, then erasing the disk key from memory? (Keep the encrypted key from the disk master block if you want to, otherwise just re-read it when needed.)

    Only after entry of

"Silent gratitude isn't very much use to anyone." -- G. B. Stearn

Working...