Blog Posts From Tagged With tls

Why is my certificate template missing from Intel SCS Console?

webadmin@intel.com — Thu, 17 Jan 2013 23:11:33 GMT

When creating an Intel AMT Configuration profile with Transport Layer Security (TLS), a target Microsoft Certificate Authority (CA) and certificate template must be specified. When using TLS with Intel AMT, a Server Authentication certificate must be defined and applied into the firmware of each system. The easiest choice is the WebServer certificate template. In some environments, this template might be disabled or removed due to security policies.

The following steps summarize the required steps.

First - if a valid Server Authentication certificate template has not be published, a screen similar to the following will occur. The certificate template field is blank with no available options

Within the Microsoft Enterprise CA, duplicate the WebServer certificate template. When prompted, select the default option for "Windows 2003 Server, Enterprise Edition"

Provide the details for the certificate template. Shown below the certificate template name is "Intel AMT TLS Cert".

On the security tab, provide access to the template for the logon account of RCSserver. In this example, RCSserver is running under the Network Service Account of a system with hostname SCS8, thus the select "SCS8$". Grant the "Read" and "Enroll" permissions

Next, issue the certificate template. Right click on Certificate Templates under the target Microsoft CA (Note: Required only for Microsoft Enterprise CA to issue certificate templates to the Microsoft Active Directory. Microsoft Standalone CA implementations do not include this option.)

With the certificate template issued...

... in the Intel SCS console, select "Refresh CAs &Templates". Via the pull down list, select the target certificate template.

Two final reminders - ensure the logon account for RCSserver (the server component of the Intel SCS installation) has rights to "Issue and Manage Certificates" along with "Request Certificates" as required for the Web Enrollment process.

And ensure the Policy Module setting allows for automatically issuing certificates

The above information is provided in the Intel SCS User Guide. This article provides a summary and reminder

Why consider TLS within Intel AMT configuration?

webadmin@intel.com — Fri, 09 Sep 2011 14:30:37 GMT

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:

Risk of data exposure to an eavesdropper
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)

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

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.

The following chart may be a useful summary:

Authentication \ Encryption	TLS	No TLS
Kerberos	Data cannot be read. Machine cannot be hijacked	Data 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.

Authentication \ Encryption

TLS

No TLS

Kerberos

Data cannot be read. Machine cannot be hijacked

Data 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)

Intel® vPro™ Security FAQ

webadmin@intel.com — Fri, 03 Oct 2008 19:34:10 GMT

This page was created to address frequently asked questions (FAQ) related to security of provisioning and configuration of vPro™ machines as well as value added security features introduced with vPro™ technology.

Intel® vPro™ Security FAQ

Top 5 things I would change about Intel AMT

webadmin@intel.com — Mon, 25 Feb 2008 07:06:45 GMT

The Intel AMT Developer Tool Kit (DTK) is now over a year old and by many accounts, the most popular software package for using Intel AMT that exists today. As I work on improvements and new features I also get to interact with my users, developers, IT departments, testers, etc. I also come across many common ideas for how Intel AMT should be improved. Today I decided to compile my own list of changes I would make to improve Intel AMT. Even if I work at Intel, I have no special access or power over what gets changed, so it’s important that users of Intel AMT make your voices heard if you think you have changes you need made.

1. No TLS, Serial-over-LAN/IDE-R password in the clear. As many of you have discovered, when using Intel AMT in small business or enterprise mode without TLS, the login username and password is sent on the network in the clear when the administrator performs a serial-over-LAN or IDE redirect operation. With so many coffee shops, schools, Internet cafes playing around with Intel AMT features, this could be a big problem. Imagine a classroom with a few vPro computers with AMT setup in SMB mode by an unsuspecting teacher. A student running a packet sniffer, obtaining the password and rebooting AMT computers remotely. This can be avoided by setting up TLS using Intel AMT Director, but this should not be problem in the first place. The HTTP digest used for web pages could easily be adapted and used.

2. Allow TLS in SMB mode. This is a long time feature request that is somewhat related to the first issue. In my work with Intel AMT, I can do everything I need to setup TLS in SMB mode except enabling it. Allowing administrators to setup server-side authenticated TLS would be very easy to add to Intel AMT and would provide improved security with almost no work. In fact, Intel AMT Commander could just prompt the administrator on first connect if he or she want to enable TLS when a non-TLS SMB computer is found. A new root certificate would be generated if none already exist. Strictly speaking, it would not provide “bank level” security, but would go a long way for shops, schools, small business owners that have more to think about than understanding secure manageability.

3. Release the SOL/IDE-R redirection source code. The library called “IMRSDK.dll” is compiled by Intel and not available in source code form. It’s available in Windows and Linux but it has been a problem for people trying to port this feature on to other platforms. It’s also a problem because this library is far from perfect and I would be the first to make changes to it. One of the most critical changes I would make involves knowing if the Serial-over-LAN is connected or not. Imagine how annoying it is to have the SOL connection drop and that application not know about it. Intel AMT Terminal will show “Connected” at the top even when it’s really not. I also want a debugging feature to know exactly what is going on, people report in forums and privately to me that SOL has problems and I have no way to help. My list does not end there; I have more changes I really need made.

4. Make Intel AMT discovery and connection easier. Some Intel AMT software have a discovery feature that attempts to sweep a network to find Intel AMT computers and add them to a management console. To make it easier on the user, Intel AMT Commander also attempts to automatically detect that type of AMT computer it’s talking to. Once you discover a computer, the work is not done. Is the computer setup with TLS? Is it in WSMAN only mode? Is it using TLS mutual-auth? Are you talking to LMS? What version is this? The Intel AMT DTK has an elaborate system to attempt gather this data when a user connects. With new version of Intel AMT, transition to WSMAN and more, it’s getting more and more difficult to correctly detect and connect to all versions of Intel AMT. Developers looking at the DTK’s connection algorithm will be stunned, we need to simplify this process.

5. Get permitted access realms upon connection. So you setup Intel AMT with various user accounts, one for asset monitoring only, one for packet control, another for remote repair. When software like Intel AMT Commander connects to Intel AMT using one of these accounts, it has no idea what types of permissions this account has. As a result, the software is left to assume it has all rights, or fail with an error when things start to go wrong. I don’t think it would be unreasonable to be able to query the allowed realms upon connection for the account currently being used. This would make it easy for Intel AMT Commander to remove from the UI features that are not allowed.

Of course, being an avid fan of Intel AMT, I could write many things I like about it, just look at my many blogs. It’s my hope that this list will spur discussion and action. If you read this, take the time to write a small comment saying which one of these would want fixed first, or tell me if you have your own issue.

Ylian (Intel AMT Blog)