Introduction
Back in 2006 Intel introduced the Intel® vPro™ brand which included as an ingredient Active Management Technology (AMT). Back then AMT was basically a desktop technology based on wired LAN Networking. Over the next few years AMT was enhanced to include mobile platforms with wireless networking Another feature included to enhance the mobile experience was Client Initiated Remote Access, or CIRA, Fast Call for Help. CIRA allows AMT features to be securely accessible to management consoles while outside the corporate networking environment. This feature being important for mobile platforms since these platforms would be used both inside and outside the corporate environment. Moreover, another industry trend has develop and matured since the early days of AMT and that is of cloud computing. While CIRA was not developed specially to address the cloud computing paradigm, it can be used to enable AMT platforms to be managed and supported in a cloud computing environment. The purpose of this article is to show how the CIRA feature can be used to securely manage AMT platforms in such environment. The content used for this article is based on a .NET Proof of Concept Intel has developed internally based on Microsoft* Azure. Although .NET and Azure were used for the PoC, the concepts and ingredients can be implemented in Amazon Web Services or any Cloud based fabric supporting similar concepts and architecture.
Ingredients of an AMT cloud computing solution
Typically, management consoles act as a client by initiating a connection to AMT devices. In this case the AMT devices acts in the role of a server (e.g. Hosting an embedded https server in the firmware) and the ISV software pays of the role of a client. On the other hand, when CIRA is being used, the firmware acts as the client and instates the connection to server. The server the firmware connects to is known as a Intel® vPro™ Gateway (also known as a Management Presence Server, or MPS). Hosting an MPS with a cloud service provider such as Microsoft Azure or Amazon Web Services can then bring AMT features into the cloud. So the ingredients of an AMT cloud computing solution becomes the following:
- AMT firmware configured to use CIRA
- Cloud hosted MPS
- Cloud Queue service
- ISV software services that support AMT features when reported to be connected via the Queue Service
The MPS
From the above diagram we can see the MPS plays the central role in the solution and so we will discuss it first. The MPS is a service that implements both external facing and internal facing interfaces. AMT devices use the external facing interface which is based on the AMT Port Forwarding (APF) Protocol. The firmware, running on the AMT clients, use this protocol to exchange messages with the MPS. The APF protocol is described in the SDK and can be implement in C++ or managed code such .C#/.NET or Java. Multiple instances of an MPS can be hosted behind a load balancer providing scalability resource elasticity common to cloud computing platforms. In addition, there are a few internal facing interfaces to each instance of the MPS and they include a standard HTTP proxy and a SocksV5 proxy for handing AMT requests in the internal cloud network. Finally, the MPS publishes connections to a reliable cloud queue storage and ISV working applications can pull the queue service for the published connections and services them. Now we will examine each MPS interface in more detail to see how messages are exchanged between AMT devices and ISV services through the MPS and the queue.
The External Interface
All the AMT devices are configured with the IP address and port of the cloud service. The external interface is a secure TLS connection and for scalability each device can be routed to a specific MPS instance through a network load balancer. Each MPS instances can handle many concurrent connections and to scale you just bring up more instances. Some load balancers automatically terminate the TLS connections at the load balancer and each MPS instance would be running in an isolated VM network after the load balancer. In case of Azure, each MPS instance terminates the TLS connection itself. In the PoC we used the .Net SslStream class to handle TLS directly inside the MPS.
\
The Internal Interfaces
Once a connection is received by the MPS, ApfConnection object is constructed with all the device info such as SystemGUID and device host name, then an ApfChannel instance is created to service each port the device is listening on (e.g. 16992/16993,16994/16995,5900). Once a connection and all of its channels are created this information published to the storage queue. ISV applications can then pull the queue and service the connection by sending AMT commands through the internal proxy interfaces. The HTTP proxy is for WS-MAN commands and the SocksV5 proxy is for redirection commands (e.g. KVM,IDER). The AMT host name is provided as part of the proxy handshake and that is used to look up the ApfConnection object associated with the connection. Once the ApfConnection is found then then messages can be routed over the specific ApfChannel and eventually make it to the AMT device over the channel.
Queue Storage
Both Windows Azure and Amazon Web Services support the concept of Storage Queues. Queues allow a reliable way for one application (in this case the MPS) to publish work for another application to pick up and perform (in this case an ISV hosted application). Many MPS instances can be publishing connections to the storage queue while many ISV worker instances can be pulling connections off the queue and servicing them. Once a connection is pulled from the queue an ISV application can now perform AMT specific tasks using the internal proxy interfaces. The connection information pulled from the queue will contain the MPS proxy address and port as well as the AMT device host name.
The APF Protocol
APF messages fall into the following categories:
- Transport Layer Messages (e.g. connect, disconnect, keep alive, version, service request)
- Authentication Messages (Optional). When connections are made using Mutual TLS then the client supplied certificates is used for authentication and authentication messages are not used. Otherwise, there can be a user name password exchange for TLS server authentication.
- Port forwarding messages-setups the connection
- Channel messages – channels are were data is sent to and received from a specific port AMT(e.g. 16993,16995,5900)
Problems address by the cloud computing paradigm
There are two main challenges addressed by using the cloud computing paradigm to manage AMT devices. First, is that of scalability were the number of clients that can be managed is just a function of the cloud computing resources one is willing to deploy. The second is discoverability, in the cloud paradigm AMT calls home to its cloud service on regular intervals and so there is no need for ISV apps to “discover” were AMT is located. As we can see cloud computing offers some unique advantages and that it is possible for AMT to participate in this evolving industry trend.
Additional links
The Intel logo is a trademark of Intel Corporation in the U.S. and/or other countries.