3 Replies Latest reply on Mar 29, 2011 2:33 PM by SafeBoot

    Question reg. Autoboot mode vs Preboot mode

      Hi,

       

      I think (some of) these questions were kinda answered in this forum before. However, I would like to get some more details about it. I would highly appreciate if somebody can provide additional input:

       

      1) If I take a copy of a Preboot encryption enabled hard disk image and an Autoboot encryption enabled hard disk image (via a knoppix live cd..), what difference would i notice?. One of my coworker insists that the .img file would be exactly the same and remain encrypted and unreadable?. In other words the 'work factor' would be exactly the same. Is that true?

       

      2) Is there any way to use EEPC v5.2.6 or 5.2.8 with TPM 1.2? Yes we understand the limitations with TPM and threats. But I getting this query quite often (from my higher ups), even after I explained the practical challenges with TPM based encryption implementation. I could not find any documentation in McAfee website/ support site that clearly talks about how to integrate or configure TPM with v5.2.x version. Can somebody provide some input and probably your experiences if you have already done it?

       

      3) In the previous post the user "Safeboot" mentioned that, incase of Autoboot mode the keys are stored in hard disk?. I did not understand that part. It was my understanding that the keys are stored in the SBFS irrespective of the preboot or autoboot. I thought autoboot just provides an option to bypass preboot using a standard $autoboot$ user.

       

      4) If your company had problems with user provisioning and temp users, would you rather choose not to encrypt or encrypt devices with Autoboot?

       

      Thanks

      J Keith.

        • 1. Re: Question reg. Autoboot mode vs Preboot mode

          1) If I take a copy of a Preboot encryption enabled hard disk image and an Autoboot encryption enabled hard disk image (via a knoppix live cd..), what difference would i notice?. One of my coworker insists that the .img file would be exactly the same and remain encrypted and unreadable?. In other words the 'work factor' would be exactly the same. Is that true?

           

          Yes, they would both look the same.

           

          2) Is there any way to use EEPC v5.2.6 or 5.2.8 with TPM 1.2? Yes we understand the limitations with TPM and threats. But I getting this query quite often (from my higher ups), even after I explained the practical challenges with TPM based encryption implementation. I could not find any documentation in McAfee website/ support site that clearly talks about how to integrate or configure TPM with v5.2.x version. Can somebody provide some input and probably your experiences if you have already done it?

           

          Yes, you can use the Infineon TPM chip with EEPC5 - it's documented in the EEPC manual AFAIK. Only the Infineon chipset though, and of course, you won't be able to "roam" users any more as their key will be locked away in one particualr TPM.

           

          3) In the previous post the user "Safeboot" mentioned that, incase of Autoboot mode the keys are stored in hard disk?. I did not understand that part. It was my understanding that the keys are stored in the SBFS irrespective of the preboot or autoboot. I thought autoboot just provides an option to bypass preboot using a standard $autoboot$ user.

           

          You are both right, and wrong. With pre-boot enabled, the key is stored on your disk encrypted with your token key (your password for example), so the "key" is not really stored on the drive, as you can't get the actual key without the password in your head. In AutoBoot mode, and this is true of EVERY product on the market, everything you need to know to get the key is stored on the drive for you. You just have to go find it.

           

          4) If your company had problems with user provisioning and temp users, would you rather choose not to encrypt or encrypt devices with Autoboot?

           

          Others will answer this, what I can say though is AutoBoot modes don't get you regulatory compliance coverage, and the vast majority of our customers solve the user provisioning problem, either with their own custom install process, or by using something like AutoDomain to do the hard work for them.

          • 2. Re: Question reg. Autoboot mode vs Preboot mode

            Hi Safeboot,

             

            Thanks for your response. I have few queries based on your answers to the question:

             

            1) So, if I mount the disk image file on preboot/ autoboot on a Mac (with firewire), do you think both will be equally or (not) vulnerable to firewire attack?

             

            2) I just checked the EEPC v5.2.8 Administration guide and I do see the TPM discussed. Thanks for the info. I think the previous versions like v5.2.3 did not have such details (if I'm not mistaken)

             

            3) So, even though the hard disk encryption key is obfuscated (probably the key bits are distributed), it  is still easier to find it in an autoboot mode..

             

            4) Yes, we are already using autodomain versions and we already have as significant population of endpoints encrypted using the this script and also through AD synchronization. Its just that temp. mobile workforce using a touchscreen based device (running xp with no safeboot drivers) that creates a unique situation. That is why we were thinking of autoboot mode (rather than not encrypting at all) as a temprory solution.

             

            Thanks again

            • 3. Re: Question reg. Autoboot mode vs Preboot mode

              1) So, if I mount the disk image file on preboot/ autoboot on a Mac (with firewire), do you think both will be equally or (not) vulnerable to firewire attack?

               

              the "firewire attack" does not involve mounting the source drive on a Mac, it involves plugging a firewire device into the running system and exploiting DMA access to cancel the login? With pre-boot enabled you can't do this as you can't boot the machine in the first place.

               

              2) I just checked the EEPC v5.2.8 Administration guide and I do see the TPM discussed. Thanks for the info. I think the previous versions like v5.2.3 did not have such details (if I'm not mistaken)

               

              It's been available for a long time - many versions.

               

              3) So, even though the hard disk encryption key is obfuscated (probably the key bits are distributed), it  is still easier to find it in an autoboot mode..

               

              In pre-boot mode the key is not obfuscated - it's encrypted. You can find the bits but it would be extremely difficult to reverse them back to the real key. In autoboot mode you really don't need to go looking even - just plug a debugger into the equation or something and just turn the machine on - it will load up the key itself.

               

              4) Yes, we are already using autodomain versions and we already have as significant population of endpoints encrypted using the this script and also through AD synchronization. Its just that temp. mobile workforce using a touchscreen based device (running xp with no safeboot drivers) that creates a unique situation. That is why we were thinking of autoboot mode (rather than not encrypting at all) as a temprory solution.

               

              It's up to you to make a risk assesment - if you have USA PII or HIPPA data on the machines, you're pretty much legally required to disclose if you loose one in autoboot mode  - but as the latest Underground Economies report highlighted, a high portion of companies stretch the law.

              1 of 1 people found this helpful