Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Security Software

Cold Boot Attack Utilities Released At HOPE Conference 113

Posted by Soulskill from the shining-a-spotlight dept.
An anonymous reader writes "Jacob Appelbaum, one of the security researchers who worked on the cold boot attacks to recover encryption keys from memory even after reboot, has announced the release of the complete source code for the utilities at The Last HOPE in New York City. The hope (obligatory pun) is that the release of these tools will help to improve awareness of this attack vector and enable the development of countermeasures and mitigation techniques in both software and hardware. The full research paper (PDF) is also available."
This discussion has been archived. No new comments can be posted.

Cold Boot Attack Utilities Released At HOPE Conference More

Cold Boot Attack Utilities Released At HOPE Conference

Comments Filter:

  • RE: Editor/Submitter (Score:4, Funny)

    by Ihmhi ( 1206036 ) <i_have_mental_health_issues@yahoo.com> on Sunday July 20, 2008 @12:30PM (#24263845)

    I think the editor and submitter both need to read this [thebestpag...iverse.net].

    • Putting on my pedantichat, I feel I should point out that he never said anything about whether his pun was intended. In fact, he seemed to be apologizing for it.

  • Yup (Score:2, Interesting)

    by Anonymous Coward

    I was there in the room when they released this attack. It was really an interesting idea of taking the memory out before decay happens and putting into another box to read stuff off of it. Of Course Physical security of a machine will solve this problem but it is a very interesting attack.

    • Why hasn't the team come forth with a fix for this exploit? They have more knowlege on the subject then I do.

      • Re: (Score:2)

        by 4D6963 ( 933028 )

        Why hasn't the team come forth with a fix for this exploit? They have more knowlege on the subject then I do.

        Well, not that I'm too knowledgeable in the domain, but don't encryption keys and such need to be decoded at some point in memory to be used?

        • Re: (Score:1, Interesting)

          by Anonymous Coward

          With multicore processors, it might be feasible to keep the key in a CPU register and not in RAM at all times.

      • because the fix would have to be in-hardware (Score:5, Informative)

        by Animaether ( 411575 ) on Sunday July 20, 2008 @12:46PM (#24263993) Journal

        and not just the machine hardware, but rather the RAM stick itself.

        Essentially the exploit relies on data that is in RAM to still exist, even if it's just for a few seconds, if you take it out of the machine.

        You could add a 'write random crap to RAM' thing to your shutdown procedure, but that won't help if they simply power the machine off.
        The machine hardware could write random crap to RAM when it is powered down, but that won't help if they simply yank the RAM stick out while the machine is still running.

        So the RAM stick itself would have to detect that it is no longer connected to any motherboard and, using a charge kept in a capacitor, for example, flash itself with random crap.. or whatever.

        Keep in mind that this 'exploit' is quite difficult to execute, requiring not just physical access to the machine - but to the RAM. While the machine is running (or was running within the last N seconds, at least). In the vast majority of environments, that's going to be extremely difficult.. unless you own (or operate) that machine and you have no particular way of being caught.

        • Re:because the fix would have to be in-hardware (Score:5, Insightful)

          by Minwee ( 522556 ) <dcr@neverwhen.org> on Sunday July 20, 2008 @01:01PM (#24264129) Homepage
          Most server class machines have intrusion detection sensors which will trigger an alarm when the case is opened. They're hardly foolproof, but if you were concerned about this sort of attack then responding appropriately to a "Your Door Is Ajar" event would be a reasonable place to start.

          • Re: (Score:1)

            by zx-15 ( 926808 )

            Hardly foolproof - well that's an understatement; since most of these systems could be easily defeated with a can opener.

            • Re: (Score:2)

              by Minwee ( 522556 )
              Nothing is going to save a server which somehow winds up in a private chop-shop where people with unlimited resources and inside knowledge of how it works want to do it harm, but try to think about more likely scenarios for this kind of attack.

        • Re: (Score:3, Insightful)

          by jeiler ( 1106393 )

          You could add a 'write random crap to RAM' thing to your shutdown procedure, but that won't help if they simply power the machine off.

          Actually, one thing that might help would be a "Decrypt then wipe RAM" scheme, where the program decrypts a file, moves the file contents into some form of buffer, then wipes the RAM location where the decryption key was stored (and if necessary, wipe the paging file). It would leave that specific file exposed, but that's a heck of a lot better than leaving the key in RAM.

          • Re: (Score:3, Informative)

            by the_olo ( 160789 )

            But then you'd have to input your passphrase each time you open a bloody file. Well if there's only few very important files, it's acceptable.

            • Re: (Score:3)

              by jeiler ( 1106393 )

              Security versus convenience. If you have no files (or relatively few files) that require this level of security, use a more convenient method.

            • But then you'd have to input your passphrase each time

              I'm sure the is a middle ground. Some desktop managers allow you to "become root" to do administrative things, and this privilege persists until an event resets it. Most commonly this event is simply a time expiration, or locking your screen.

              The same could be done for your keys, and doesn't seem too onerous on the user who knew [s]he was going to have to sometimes enter a password to decrypt the files.

        • Re: (Score:1)

          by mysidia ( 191772 )

          So the RAM stick itself would have to detect that it is no longer connected to any motherboard and, using a charge kept in a capacitor, for example, flash itself with random crap.. or whatever.

          So then the attacker solders a wire to your capacitor, and shorts the capacitor to ground the moment they cut power to the RAM stick.

          • Re: (Score:3, Insightful)

            by Eternauta3k ( 680157 )
            Unless they pot it, or stick it somewhere inaccessible. Of course, someone determined enough will find a workaround (I mean CIA, not random hacker)

            • Re: (Score:1)

              by IdeaMan ( 216340 )

              Ok, that's it.
              Just bloody encrypt ALL RAM!
              CPU hashes key in BIOS with key in memory controller and key in ram chip.
              Yank the ram and the key no longer matches.

              Cache misses will be a bear though...

        • > So the RAM stick itself would have to detect
          > that it is no longer connected to any motherboard (...)

          Have you seen Mission: Impossible? They've done an interesting thing with the laser beams that served as an intrusion detection system there. I wonder if a similar hack could be achieved by plugging out the ram stick, without disconnecting it from the mobo (or rather: sequentially disconnecting it and reconnecting to your hackbox on the fly).

          Then again, if it's a server, then a decent intrusion detec

        • Keep in mind that this 'exploit' is quite difficult to execute, requiring not just physical access to the machine - but to the RAM. While the machine is running (or was running within the last N seconds, at least). In the vast majority of environments, that's going to be extremely difficult.. unless you own (or operate) that machine and you have no particular way of being caught.

          No you don't, play with the PoC. With McGrew Security's ramdumper you've been able to boot off USB on the machine the ram sat in i

          • yeah, except when I'm working at a computer and somebody comes over and says "Hi, would you mind terribly if I plug this USB stick in and reboot your machine?", I'd probably say "why yes, I would mind terribly".

            And if I'm not at the machine, quite likely, I powered the thing down... that gives the person with the fancy USB stick mere seconds to move in and quickly plug the key in and boot back up.

            Don't get me wrong, I already understand that it is possible - just that the situations in which it is possible

            • Re: (Score:2)

              by the_olo ( 160789 )

              You're only imagining scenarios where the attacker is in a criminal minority and the user is in a secure environment that's hostile to the attacker.

              What about situations where the attacker is actually a majority on the scene (e.g. a government band of crooks who just rushed into the user's home) and the environment becomes hostile to the user? The attacker has all the time at his disposal, the only thing the user might had time for was quickly powering off the machine. I think that's the scenario that m

            • Re: (Score:2)

              by VdG ( 633317 )

              Don't get me wrong, I already understand that it is possible - just that the situations in which it is possible are not extremely likely to occur.

              Apart from those likely to be facing the forces of law and order exercising search warrents, the biggest risk would seem to be for people losing laptops. It is suggested that PCs which are in hibernate/suspend states may not be safe. Personally, I don't tend to suspsend my PCs when I'm finished with them for the day. But I do sometimes and may suspend one with the expectation of restarting it later, only to get caught up with something else. These machines could be vulnerable.

        • The DRAM cells are basically little capacitors that store the charge. It should be quite easy to have a single line going into the the DRAM that flushes all the cells as soon as: power is removed, refreshing fails or an external reset is applied.

          The other trick is to write the random crap, or apply the clearing, when a DRAM is powered up. That way the RAM would get cleared even if yanked from a hot box.

      • Re: (Score:3, Funny)

        by DAldredge ( 2353 )
        Because changing the laws of physics is hard.

      • Some partial fixes are possible and were discussed a while ago.

        http://thread.gmane.org/gmane.comp.encryption.general/11528 [gmane.org]

      • Why hasn't the team come forth with a fix for this exploit? They have more knowlege on the subject then I do.

        The key speaker mentioned that ECC ram scrubs all bits right after startup so its one possible defence (though not very effective still because reports are not throughly tested). Another would be to setup a timer that scrubs the memory if the machine has been idle for a given amount of time....one fancy version was to have your machine trigger the scrubber once your cellphone (running a tracker) had been away for a certain duration. The decay time (IIRC) was an average of 25 seconds.... BTW while you're at

  • If you want to imagine the future, picture a cold boot attack on a human face, over and over, forever.

  • Isn't there a memory wiping utility that fills the memory with random noise?

    • Re:Memory wiper? (Score:5, Informative)

      by jonbryce ( 703250 ) on Sunday July 20, 2008 @12:47PM (#24264003) Homepage

      You cool the chips down in the running computer with a spray duster, pull them out, and put them in a computer that you control.

      No software solution can be used to stop you doing this, it has to be a hardware based solution.

      • I think what the GP was saying is that you could do something like:

        After a period of timeout have the computer wipe the encrypted key in memory using DOD passes on the areas of memory the key was in.

        Or have the system automatically run a DOD memory wipe on shutdown.


        Unless I'm not understanding the problem about the only thing these wouldn't prevent would be a cord-yank-shutdown of the system if the person were fast enough to get to the system before the wipe timeout.

        There'd obviously be overhead in the

        • After you wipe the key from memory, you are going to need to have some user interaction to remount the disk. That may not be practical.

          • So make it a quick inactivity timer and tie it to the screensaver so you have to re-enter the encryption passphrase before being able to work again.

            I don't think this exploit is a serious issue while the person is working. The minute they walk away or lock their screen though...

      • Re: (Score:1)

        by mysidia ( 191772 )

        The solution is: don't store an unencrypted version of the key in RAM.

        Have the decryption require input from a tamper-proof smart card.

        If the smart card loses communication with the system, the smart card is programmed to stop operating, until the user re-authenticates.

        An attacker can pull and access the entire RAM, but it's useless without also having the smart card.

        • Re: (Score:1, Insightful)

          by Anonymous Coward

          The problem is that all I/O for encryption needs to go through the key, so having the key only available on a smart card would cause great performance losses. Smart cards are intended for very low bandwidth uses -- decrypting a volume key so the bulk decryption can finish, or signing a MD5 hash.

          Instead, perhaps move the encryption to the drive controller and have some keymanagement abilities there. Then, come a shutdown, its a lot easier for a drive I/O controller to wipe its limited RAM than for a PC to

      • Re: (Score:2, Interesting)

        by freddy_dreddy ( 1321567 )
        You can store the keys in video memory, you can't pull those out of a laptop. And yes, it's not only possible but also rather easy. Storing them in the lower part (first 64kb ?) which is used to display the "boot screen" will actually create an automatic sweep. Both backdoors locked.

        • Re: (Score:2)

          by the_olo ( 160789 )

          Yeah, but you can't quickly poweroff a laptop. You have to keep the power button depressed for a couple of seconds, enough for the bad guys to take it away from you.

          • Re: (Score:2)

            by neomunk ( 913773 )

            Until this point I hadn't considered the fact that my laptop battery degrading to the point of *immediate power-off when plug is pulled* could be a feature.

            Thank you HP!

          • Most laptops I've used have a pretty quick release on the battery. Pulling the power cord and popping out the battery in a couple seconds doesn't seem unreasonable.

      • Re: (Score:2)

        by Tuoqui ( 1091447 )

        Theres a hardware solution, its called a boot to the head.

      • I remember a number of systems that had case intrusion switches that would alarm. I don't see any reason why that couldn't also be tied in to an autoshutdown procedure that'd wipe the RAM.

        Less obviously, the switch could trigger a special watchdog program that knows where your crypto keys are stored, and overwrites them when the sensor goes off.

      • Re: (Score:2)

        by Nethead ( 1563 )

        ...it has to be a hardware based solution.

        Spray epoxy. ("This is glue ... strong stuff." -Elwood Blues)

  • There are some ways to minimize the problem (Score:5, Interesting)

    by Psionicist ( 561330 ) on Sunday July 20, 2008 @12:45PM (#24263979)
    The way I see this, you should simply not store keys in memory (that is have your encrypted file system mounted) when you not need access to the files. A correct program will overwrite the keys when the file system is dismounted.

    The purpose of full disk encryption (or system encryption in TrueCrypt is), in my opinion, not meant as a "one password to protect everything". It's just an extra measure to secure temporary files, the swap file and other tracks the OS and applications may spread around. You should still encrypt your really secret files separately, and use basic precautions such as secure file erasure when you've used them.

    That said, I still don't think this attack is so important. If you have the file system mounted, and an attacker gains access to your computer, the files are already there!

    • Re: (Score:3, Interesting)

      by Anonymous Coward

      The whole point of this is unclean shutdown. How is your computer going to overwrite the keys in memory when someone pulls the plug?

      Sometimes the mere presence of a file, encrypted or not, is "incriminating" enough. Ask Kevin Mitnick about NSA.TXT on a floppy he had - it was a listing of a host with the registered users at the National Computer Security Archive, and that got quickly spun to "having compromised the security of the NSA".

      Sometimes you want to hid the existence of information, not just the in

    • Re: (Score:2)

      by the_olo ( 160789 )

      That said, I still don't think this attack is so important. If you have the file system mounted, and an attacker gains access to your computer, the files are already there!

      This attack is important because until now it has been perceived, that if in a last effort you pull the plug out of your box and render it powerless, your encrypted filesystems will be safe.

      The common opinion was that when the DRAM modules get their power cut off and their refreshing stops, all contents are almost immediately lost, a

    • Re: (Score:2)

      by VdG ( 633317 )

      I'm sure I recall something from last week about individually encrypted filesystems not being secure because the OS will store data - e.g. documents being edited, or recovery files for same - in non-encrypted areas. So the only way to be safe IS to have the whole disk encrypted.

      I think what it really shows is that there's no absolute security.

  • So a computer is a box. It has four sides, a top and a bottom. Some may not have four sides, this is irrelevant.

    The solution to this is a hard hack (well one solution anyway). Case is opened without putting a magnet in JUST the right place (or some other measure) and memory is fried.

    Do X rays fry memory? Anyone?

    • By "do X rays fry memory" I mean, will they scrub chips of any data (I was not speaking about damage when I said 'fry')

      • Re: (Score:2)

        by the_olo ( 160789 )

        Alpha particles cause errors in memory chips - see jargon file [mcgill.ca]:

        Intel could not explain random bit drops in their early chips, and one hypothesis was cosmic rays. So they created the World's Largest Lead Safe, using 25 tons of the stuff, and used two identical boards for testing. One was placed in the safe, one outside. The hypothesis was that if cosmic rays were causing the bit drops, they should see a statistically significant difference between the error rates on the two boards. They did not observe such

    • Re: (Score:2, Interesting)

      by Sir_Lewk ( 967686 )
      You can hardhack your way around any hardhack.

      • Re: (Score:2, Interesting)

        by rwillard ( 1323303 )
        While it's true that you can bypass any hardhack security system, surprise can be a great asset. Most people, even Law Enforcement, aren't going to expect your computer to fry itself if opened, or whatever system you use. It's the kind of trick that will only work a few times, but a few times is probably enough.

        A lot of the new 'cool' law enforcement devices are USB, for easy access and easy reading of the computer. Imagine a computer that has three in-use USB ports and one open slot, and plugging a devic

        • Re: (Score:2)

          by VdG ( 633317 )

          Even with cooling, the memory doesn't linger all that long so all that's really needed is to delay removal of the chip(s) for long enough. Eposxy or something similar to fill in screws and secure access panels might suffice. Of course, that would make your own maintenance difficult. Glueing in the memory chips themselves might be better as it would be difficult to get them out using brute force without damaging them.

    • Re: (Score:3, Insightful)

      by kesuki ( 321456 )

      thermite packed around the ram seems the best way to go. then if they tamper with the case, it triggers a 'tramper switch' the thermite goes off, and boom just a molten blob of goo. also, if you're going to have a self destruct on the ram, you may as well do the HDD as well, and you might as well throw in a manual switch along with the 'tamper switch' in case the FBI comes knocking, and have a good plan for how to circumvent your 'tamper switch'.

      thermite is a bit extreme, but if you want your data irretriev

      • Re:Tamper proof case, anyone? **MOD PARENT DOWN** (Score:1, Informative)

        by Anonymous Coward

        The parent poster to this post shouldn't be marked as insightful as the poster hasn't got a single clue what they are talking about. Quote:thermite goes off, and boom just a molten blob of goo.

        Goes off? Boom?!? WTF?!? The poster obviously hasn't even got a basic clue what they are talking about. Indeed to quote wikipedia at a basic level: "....It is not explosive, but can create short bursts of extremely high temperatures focused on a very small target for a short period of time...."

        Hence why Thermite

        • Re: (Score:2)

          by kesuki ( 321456 )

          the 'boom' wasn't an explosion, besides I've seen a thermite loaded laptop go off, in video with audio, it's a lot like a very large firework, hissing with a big gout of flame. the boom was just slang, because the data will be destroyed in a very entertaining way.

          you should read up more on slang, since you assume boom means explosion, 'bang' means explosion. http://www.urbandictionary.com/define.php?term=boom [urbandictionary.com]

          • Re: (Score:1)

            by kesuki ( 321456 )

            I realized now 'Kaboom' == cartoon explosion not boom, completely different words man.

      • A candidate for the Darwin Awards (Score:2, Funny)

        by Anonymous Coward
        So, do you use this thermite enabled system on your LAPtop?

  • Capturing machines with full disk encryption (Score:5, Interesting)

    by Animats ( 122034 ) on Sunday July 20, 2008 @01:02PM (#24264157) Homepage

    Here's the existing approach to this problem.

    1. Send in SWAT team. Stop user from turning off computer.
    2. Bring in HotPlug kit [wiebetech.com] and UPS.
    3. Plug "Mouse Jiggler" into USB port to keep no-activity timeout from causing logout.
    4. Turn on UPS.
    5. Plug HotPlug unit into UPS.
    6. Plug HotPlug unit output plug (a male plug which is a power output) into power strip, or, if necessary, remove wall outlet plate and connect clamp-on connectors to hot wires.
    7. Unplug power strip from line power. HotPlug unit will switch in power from UPS.
    8. Plug power strip into UPS. HotPlug unit will recognize this and deenergize its output plug.
    9. Unplug HotPlug output plug and input plug. Computer is now running entirely on UPS.
    10. Carry computer and UPS to forensics lab before UPS battery runs down.
    11. Plug in UPS to keep battery charged.
    12. Access disk as desired.

    • Re: (Score:2)

      by bazorg ( 911295 )
      looks like a forced login every 10 minutes is a good idea for people working with really sensitive data.

    • 13. Try not to get hit by truck as you maneuver Frogger machine across street.

    • Re: (Score:1, Insightful)

      by Anonymous Coward
      Sounds a bit complicated. Here is how it's done:

      1. Get physical access to computer, install hardware keystroke logger.

      2. Wait a few days.

      3. Seize computer, decrypt harddrive.

      Or, for the lazy ones:

      1. Park van with Van Eck device at next corner, record keystrokes.

      2. Seize computer and decrypt harddrive.

      Or, for the people that prefer to stay at home/office:

      1. Break into system over network.

      2. Download data over network.

      Or, alternatively but more risky:

      1. Seize computer.

      2. Decrypt harddr

      • For your first alternative physical intrusion detection will work very well as a safety measure since the attacker wants to be discrete. If you return home and notice somone have drilled/sawed/cut a large hole in the side of your computer would you be suspicious?

        As for the Van Eck device, there is a reason military systems that needs to be secure outside of a secured enviroment is usually quite bulky, thats because they are shielded. If your data is so important that you need to worry about three letter
    • Honestly, neat but if your smart have your power button set to five second shut down. By the time they get to it, its off. O well. Also, hotplug doesn't work in the US because we actually insulate our plugs with plastic.

    • Re: (Score:1)

      by ofc ( 311641 )

      Interesting, I hadn't thought about them taking away my TOR node while it was running.

      It shouldn't be too hard to fix this:
      The machine can be configured to shutdown when it detects hardware changes, like the insertion of the "Mouse Jiggler" or the removal of ethernet cables.

    • Re: (Score:2)

      by Deagol ( 323173 )
      Thought experiments like these are fun, and sometimes even productive. After I first read about the Firewire/DMA attack, I got to thinking about about various hardware seizure scenarious, much like you describe.

      I've concluded that the only really decent protection is a series of software heartbeats tied to the physical environment in which the computer operates.

      You can monitor voltage of various parts of the PC and UPS, so this might help against in the case where a machine's power source is tampered w

  • Among the many things that can be done to a machine when someone has physical access, this isn't my primary worry.

    And if you don't run encrypted swap space, don't worry about this.

    • It is of great concern. Many corporate users live in the false sense of security that their (personal and corporate) data is secure should the laptop get stolen. But this no longer holds true if the laptop stolen was either in hibernation mode (sleeping) or just password locked. That might also hold true for the guy that is walking around with millions of SSNs on his laptop, including yours.

      • If the company lets people leave the office with laptops containing "millions of SSNs", this exploit isn't their biggest problem.

        I have to agree with the OP. So far in the entire thread I've yet to see a convincing argument explaining why this is a big problem.

        At most it seems this would be a small concern for a very, very small group of people. And before anybody gives another parnoid explanation involving SWAT teams and the CIA, ask yourself how often that really happens.

      • Many corporate users live in the false sense of security that their (personal and corporate) data is secure should the laptop get stolen.

        Yes, they do, but not because of this. Among the many things wrong with corporate laptop security, this is way down on the list.

        (It's also not news to anybody who has ever power-cycled an Apple II.)

        That might also hold true for the guy that is walking around with millions of SSNs on his laptop, including yours.

        Tens of thousands of people have access to my social security

  • One way to make memory contents much more difficult to recover is this. The CPU(s) will have a key stored internal to the CPU chip, in SRAM [wikipedia.org] (memory held in state by power, a technology that does not lend itself to the high density that DRAM [wikipedia.org] does). Initially the CPU runs in "clear mode" and establishes the key. Then it proceeds to encrypt memory, except for the page the encrypt program runs in. Then it enters "crypt mode", which includes a jump to a new address outside of the clear page. In "crypt mode"

    • Re: (Score:2)

      by tftp ( 111690 )

      In "crypt mode" all memory fetches are decrypted in hardware, and all memory writes are encrypted.

      The CPU is not the only entity who writes or reads RAM. Every DMA device does that, such as video, HDD, USB, Ethernet... in fact, most peripherals, including those mounted on the motherboard. Either the key has to be shared with them (which is not secure) or these DMA pages remain unencrypted (which is not secure.)

      The one obvious solution here is to implement secure encrypted path to all these devices, li

    • Re: (Score:2)

      by the_olo ( 160789 )

      SRAM is constructed from latching circuits. Anyone knows what's their volatility when compared to DRAM? Do they lose contents immediately when powered off or do they retain the state for some time like DRAM?

      If it's the latter then the attack might still be doable on the architecture that you propose because the keys would still be there on the SRAM page in the CPU. The difference is that you couldn't just plug the CPU in to a different unmodified general purpose PC, because CPU initialization during boo

      • SRAM is constructed from latching circuits. Anyone knows what's their volatility when compared to DRAM? Do they lose contents immediately when powered off or do they retain the state for some time like DRAM?

        [Disclaimer: The following was from many years ago...]
        From my experience of a home computer (in the early 80s) with (CMOS) SRAM memory, the contents stay almost intact with a switch off of a second or less and gradually decay to "random" if the power is off for several minutes. IIRC given that CMOS uses MOSFETS which also have tiny capacitors, this is perhaps not too surprising.

  • If the attacker has physical access to the machine to begin with, you might as well throw in the towel.

  • Does anybody know whether all current cryptographic implementation properly overwrite memory regions that contained keys when the keys are no longer needed?

    I wonder if LUKS (Linux Unified Key Setup) does that properly when you do a "cryptsetup luksClose"?

    Once the encrypted filesystem is unmounted and the encrypted device removed, and the encryption key properly overwritten in memory, I figure at that moment you are safe from that attack?

  • The hope (obligatory pun)...

    Nobody cares if your puns were intended. [thebestpag...iverse.net]

  • Used to rip music on this Amiga by loading the game (or demo or whatever) warm boot the machine to a shell and dump the contents of memory to disk and look for the appropriate headers.

    You could do the same thing on a pc really - just warm boot the pc and don't initialize the ram.

  • I salute the authors for their efforts, as this is a significant and welcome contribution. But I have to respectfully disagree with this statement:

    "There seems to be no easy remedy for these vulnerabilities."

    Yes there is. All one has to do is misprogram the DRAM controller. And then wait until DRAM is fully discharged before continuing on with the boot sequence.

    For those who aren't familiar with how DRAM controllers work, they are responsible for laying out memory as seen by the CPU. There are a whole b

  • The following is we implemented in our shop to prevent cold-boot attacks. Our shop is a Panasonic Toughbook shop, so keep that in mind as some features in the Toughbook line of laptops may not be available, but most of them are.

    1.) Establish a system administrator password in the BIOS. Also establish a user password in the BIOS as well.

    2.) Enable the feature to require password entry in order to boot the system.

    3.) Hardware lock the hard drive to the system using the system administrator's password est

    • Not sure if you are aware but it is pretty trivial to bypass ATA password lockouts if you really want to... all you have to do is swap out the controller chip and/or controller itself on the drive. You can usually do this without even having to remove the platters of the drive.

  • Have the SanFran IT system admins gotten into a running conversation with this team yet?

  • After reading the "Key expansion" defense, I got to thinking. Perhaps a fuzzy margin for the key length could be built into these crypto schemes? I know that common algorithms seem to usually be in multiples of, say, 128 bits (AES 128 and 256, for example). I've never tried using a weird bit length for anything (say, AES with 231 bits), and I don't know if these algorithms can even use such an odd key.
    However, if they could, maybe during initialization the user could be prompted for a bit length and fu

Slashdot Top Deals

Genius is ten percent inspiration and fifty percent capital gains.

Close