As many of you may know, there are two ways of contacting Intel AMT: The remote network interface and the local LMS/HECI interface. These interfaces are very different; the remote interface that is available thru the wired and sometimes wireless Ethernet and is rich with features while the local Intel AMT interface is very limited. Intel AMT was designed this way from the start for security. Intel AMT acting as an IT agent on desktops and laptops could not be allowed to be meddled with by the local user or local applications that could try to use or deactivate Intel AMT. That at least was the original design intent.
Times have changed it seems and many users of Intel AMT don’t see local users and applications as being always hostile. There are many reasons why it would be very interesting to access all of the features of Intel AMT locally. For example
- If the user changes the name of the computer is the OS, it would be nice to have a local agent sync up the Intel AMT network with the OS name automatically. This way, when the computer goes to sleep next, Intel AMT will report the correct new name.
- Circuit breaker policies could be used as a local firewall implemented in hardware. Set it once and the gigabit network chip does all the filtering and counters at gigabit speeds.
- On a mobile platform, wireless profiles could also be synched up automatically. The user adds a new wireless profile with a WPA key and this profile is automatically added to Intel AMT.
- Enterprise provisioning of Intel AMT could be done entirely locally using local software removing the need for complicated centralized servers.
Instead of seeing the local user as hostile, the local application now cooperate to setup Intel AMT so that if something goes wrong, it’s ready to be used to recover the computer. All this and more would be possible if Intel AMT allows the local applications full access to all the remote interface features.
A local application can’t simply connect to TCP port 16992 or 16993 and access all of the Intel AMT features since the traffic has to flow thru the gigabit network interface. Connecting to 127.0.0.1 will not work, that will access the more limited local interface.
A solution is to use a reflection application like Intel DTK Network Reflector found in the Intel AMT DTK. This tool runs on a central always on server and simply reflects back all TCP connections back to the source on ports 16992 to 16995. Using this tool an Intel AMT console or even a web browser can connect to "http://reflector:16992" and log into its own Intel AMT remote services. However, there are issues with this solution: You need this reflector tool running and know where on the network it is running. Also, a rogue application could log into the remote interface and put an annoying circuit breaker policy to drop all packets, etc.
In the future, Intel AMT itself could be modified to allow all services on the local interface removing the need for the reflector. There are security considerations of course, but feedback from users of Intel AMT on this idea would be appreciated.
Ylian (Intel AMT Blog)
