If you are concerned about securing communications on your internal network, here are a few items you should know.    Be sure to share these insights with those you might not be concerned.   This blog provides a few more insights beyond to the statement "Risks of not using TLS" found in the vPRO Security FAQ .


Two key security risks should be considered in regards to Intel AMT network traffic:

  1. Risk of data exposure to an eavesdropper
  2. Risk of machine being hijacked by an eavesdropper


Key points to consider for these risks:

  • Intel AMT authentication method used (i.e. Digest or Kerberos)
  • Encryption of Intel AMT network traffic (i.e. no-TLS or TLS)


Focusing in on the risk of data exposure, if no encryption is used communications to Intel AMT are in the clear on the network.   An eavesdropper can see data sent back and forth.   The majority of the data will be Intel AMT messages over HTTP or WS-Management traffic.    In addition to Intel AMT traffic, the eavesdropper will see other communications between the client and the infrastructure.   (Side note: This assumes the eavesdropper has placed a network sniffer between the client and infrastructure connection AND that they know when to capture packets specific to Intel AMT.   If the eavesdropper is capturing packets between the server and network infrastructure, they will likely be looking for more than Intel AMT related traffic)


To address the data exposure risk, use TLS with the Intel AMT configuration.   The method of authentication (i.e. Digest or Kerberos) will not address the data exposure risk.


Focusing on the risk of hijacking requires a little more understanding of Intel AMT authentication.   If Kerberos authentication is used, no username or password are sent on the network.  Instead, Intel AMT authentication is handled via a Microsoft Kerberos sequence with the Intel AMT device acting as a network service.   If Digest authentication is used, the majority of Intel AMT use cases require an MD5 digest authentication.    In this scenario, the username for authentication is sent in the clear but the password is a hashed nonce (i.e. hashed value calculated based on that specific session using among other items the password value known by server and client).    The exception is redirection scenarios (i.e. IDE-Redirect and Serial-over-LAN).    In these scenarios, if digest authentication is to be used the username and password are sent in the clear.


To help reinforce the above points, there are 3 images below of various network traces.


The first image shows a network capture of an MD5 Digest authentication to Intel AMT for a power-on event.  Note that the username is seen, but the password is a nonce value. (which cannot be repeated\replayed)

MD5 Digest.png


The second image shows network capture with digest authentication during an IDE-Redirect session.  Note that the username and password are in clear text.

Digest IDER.png


The third image shows network capture with digest authentication and TLS enabled.   What you see is the TLS session being established followed by garbled data due to the encryption.

Digest TLS.png


The following chart may be a useful summary:



Authentication \ EncryptionTLSNo TLS
KerberosData cannot be read.   Machine cannot be hijackedData can be read.   Machine cannot be hijacked
Digest (Username/password)Data cannot be read.   Machine cannot be hijacked

Data can be read.   Username can be captured.

If using redirection, password can also be captured.





A few additional points to consider:


  • If you are not planning to use Intel AMT redirection and want best performance, a Digest with no-TLS situation may be preferred.
  • From a performance standpoint, a simple digest authentication with no-TLS (i.e. no encryption) will be the best situation.  
  • The longest latency will occur with TLS added to the Intel AMT configuration.  
  • Both Kerberos and TLS will require the FQDN of the Intel AMT device to be synchronized with the operating system hostname and correctly resolved within the infrastructure. 
  • Adding TLS configuration to Intel AMT will require an internal Certificate Authority with the root certificate applied to all systems accessing the Intel AMT device
  • If you want to ensure that only certain management systems are able to communication with Intel AMT systems, a mutual TLS configuration is recommended (note: this is very rare and may not be supported by all Intel AMT capable applications)