4 Replies Latest reply on Jul 14, 2009 10:16 AM by spabercr

    vPro tampering

      I need some info on how vPro is secure from tampering attempts:


      Can it be disabled in any way?  (eg. via BIOS, etc)


      What happens if someone takes out hard drive of the vPro enabled computer/laptop?    Could they re-use the drive by plugging into another computer?


      Does vPro have any type of encryption technologies that would disable the drives/data?

        • 1. Re: vPro tampering



          I've already posted about this: http://communities.intel.com/thread/3490


          But I know that the vendor can disable VPro at their factorys before it reaches your site. I've also disabled the Fujitsu 5730 desktop VPro by using the BIOS and the VPro's mini bios menu setup, then proctecting with a password. But this is still hit and miss. I want to be able to control the VPro software at the BIOS level on all machines that have VPro technology, just like I can with serial ports or IR ports. Having VPro running in the background gives sys admins great control over their entire estate. But it also opens up the ability for abuse and the possibility of compromising both privacy and security.


          It would be nice to have some more feedback about this topic. Anyone from Intel want to wade in?

          • 2. Re: vPro tampering



            I have already posted to this forum about my concerns : http://communities.intel.com/thread/3490 but to date have had no response.


            The vendors can disable the VPro technology at their factorys and I have also managed to lock down VPro on a Fujitsu 5730 desktop by using the BIOS. What I would like to see is a direct and simple way to disable VPro in all machines regardless of vendor.


            At this moment, VPro will allow sys admins to access machines on their entire estate. But if the ability is there then the possiblity for abuse is also there. Some organisations like the DoD will see this as a hugh security hole. They would want to disable in the first instance and then work out a way to make use and secure it for the future. Not having control over your own machines screams of Big Brother, and I'm not talking about the crappy TV show.


            I would really like to see some feedback from Intel about these concerns. In fact, I would love to see some feedback from anyone in this community. Come on people, lets get talking about this issue.

            • 3. Re: vPro tampering

              Sorry about the double post. Didnt think the first made it across the wire... oops

              • 4. Re: vPro tampering

                So I commented on your security question and have seen you post a few other requests on controlling vPro like a USB port or other HW device. AMT is a independent computer with its own controller, Operating system, security and network port address (there are articles that review how the Management Engine and its components interface to the main chipset and LAN infrastructure that go into detail, you may want to read thru them). ME is designed so only REMOTE connections thru secure servers can access the Client.


                But to answer your question, to do any type of control you first have to fully activate AMT on the network, here is a quick review of what you have to have in place to accomplish this task. Cleints have to be provisioned, this requires a setup and configuration server to "reflect" back to the client system, without this "reflector" you can not provision AMT.  SCS communicates thru HTTPS (TLS) to the client platform and then must push a provisioning certificate to the client.


                So to touch AMT on a client you need

                     a properly configured SCS server joined to a Domain with a CA server providing it with proper credentials on the network.

                     Running over a TLS connection

                     Authenticated thru the Domain to receive a provisioning certificate that is unique to the client.


                Again, review the AMT/ME FW security papers, there are internal audits and filtering that also monitor all data packets to prevent spoofing or malicious attacks, its very serious about protecting the client.


                if AMT is turned off in the ME then you can use a tool called Activator, it is for the Client to request the activation.  It has to have activator available on the O/S, pass the server name to allow the SCS to authenticate its credential then turn on AMT and provision it thru the same security network from above for a final configuration. For sheer complexity it would be easier to  attack the main operating system than go after a FW stack that is desinged to prevent unauthorized access.


                It should be noted that while there is a BIOS setting for AMT - this does NOT always disable the capability, it typically suppress the Ctrl-P but the FW is available in a passive secure state (we recommend you contact the OEM to determine if they Turn off ME (Management Engine) thru a bios switch) to truly disable AMT you must be able to either have the OEM disable it in the factory or you need to partially provision each client by manually entering the FW thru Ctrl-P, set a hardened password and enter the Management Engine Features section, and set Features = NONE, one othere way is to obtain a BIOS image with a full ME component in it from the OEM and remotly update the BIOS with the ME seciton set for Features = None.