6 Replies Latest reply on Feb 18, 2010 8:21 AM by peter_eepc

    Autoboot Documentation.

    safebootsamurai

      I know it has been covered in great detail on this forum. However, the client i'm working with has a set of machines they would like to encrypt but due to a large number of users that will need access (several hundred a year) they would like to autoboot the machines. Currently the users are logging into windows (i think locally?) with a generic login and then running applications hosted in a citrix environment. They are looking for an official looking McAfee document that covers the autoboot process as well as the dangers of using it. They also would like some detailed information on how the keys are stored and what would need to take place for anybody who gets a hold of an encrypted machine that is autobooting to actually decrypt the device and gain access to the data. Other than for patching purposes does a McAfee document exist that covers autobooting that has specific reasons why they will claim the machine is not protected in the autoboot state?

        • 1. Re: Autoboot Documentation.

          nothing official, as if you remember, this situation is explicitly excluded from the EULA (and you agree to lots of nice T&C if you use it).

           

          I did blog about it a while ago if that's interesting:

           

          http://simonhunt.wordpress.com/2009/09/03/is-encryption-enough-why-just-encrypti ng-data-doesn’t-solve-today’s-information-security-concerns/

           

          But the bottom line is, for any system to boot without needing a user to authenticate, the keys must be stored in a plainly accessible way on that system - regardless of vendor. So, for a hacker, all they have to do is work out where the key is

           

          personally, I'd use a firewire or cold boot attack to get into a machine like this. Your only protection is after all the Windows login prompt.

          • 2. Re: Autoboot Documentation.
            safebootsamurai

            It make sense to me and the IT people, but the people they report to up the chain lets just say the User community seems to be in charge.

            • 3. Re: Autoboot Documentation.

              Get your account manager to set up a call between your "powers" and the McAfee Data Protection CTO to discuss?

              • 4. Re: Autoboot Documentation.

                The problem is if you use multiple protection systems to secure your data. If say, you have deployed EEPC on a system that uses hard disk hardware-encrypted with a password, unlocking only one protection system does not expose data. One would need to conquer all protections to get that.

                 

                I think this is why we have so many discussions about autoboot. Similar to autoboot is EEPC SSO. Just EEPC and Windows roles reversed.

                • 5. Re: Autoboot Documentation.

                  The problem is, most people think the Windows login provides "security" of the data - where it does not. To get the data off a machine protected by a Windows password prompt. you just have to slave the drive, or boot off a USB stick, or even simpler, just reinstall Windows. Voilà! all your data accessible. How to get around a Windows login is a well publicized and well known thing.

                   

                  To protect the data you need some form of encryption - EFS, File encryption, ZIP encryption, Virtual Volume, or Full Disk. Then having a password actually "means" something - it's actually doing a useful job. Then comes the question of data recovery...

                   

                  Without encryption, all you're doing by using user id's and passwords is getting a personalized experience.

                  • 6. Re: Autoboot Documentation.

                    And most of people think, because you cannot just

                    you just have to slave the drive, or boot off a USB stick, or even simpler, just reinstall Windows. Voilà! all your data accessible.

                    with EEPC encrypted disk, therefore data must be safe. It is harder to get to (as you say) but not impossible in many cases.

                     

                    I assume that you have used those two methods (firewire or cold boot attack) with success, just to prove vulnerability in that area.

                    Interesting if the same rule would apply to computers with disabled firewire ports and hibernation/standby features.