Performing Remote Configuration with Java

In my last Java blog I demonstrated how one could perform Host-based configuration of AMT with Java. Now I’m going talk about how to perform Remote Configuration. The differences between Host-based and remote configuration lies primarily on were the configuration code runs and the security requirements to execute the code. With the Host based method, our requirements were that we needed to run with admin privileges on the AMT client itself. With the remote configuration method, our requirements are that we need to run on a separate machine, over a wired network connection, using a setup certificate trusted by the platform. In addtion, the setup certificate subject name must be issued to the DHCP option 51 reported Domain name. If we are missing any of these requirements then we will be unable to perform remote configure AMT. Keep in mind these remote requirements apply only to the initial configuration of AMT. After AMT is configured we will be free to use wireless networks or static IPs and all that. From a Java perspective not much is different from the Host-based method. In both cases we will be using WsMan commands to perform the configuration. The real difference is how the WsMan connection is established.

To establish a remote connection in Java, we need to load a setup certificate and tell Java to use it. In the real world, the organization deploying AMT will acquire the setup certificate from a trusted web authority. However, for develop and testing we can generate our own test certificate and manually configure our machine to trust it, so we don’t have to acquire a real would certificate from web authority.
The Java code creates a TLS session using a setup certificate then sets some data and finished the remote configuration by calling CommitChanges(). Here is what the code looks like:"https://myAmt:16993/wsman"); defAuth =

// for remote configuration the digest password is always admin/admin since the Setup Cert is our credentials
"digest", "admin", "admin");;

// create a default trust managager for TLS authorization
DefaultTrustManager trustMgr = new DefaultTrustManager();
// for remote config we will skip host name verification against the certificate but we can use the OTP instead for security

// Load the amt setup certificate and private key into the trust manager
DefaultKeyManager keyMgr = new DefaultKeyManager("c:\AmtSetupCert.pfx","123");

ManagedReference ref = connection.newReference("AMT_SetupAndConfigurationService");

ManagedInstance inst = ref.get();

//setting data is optional (unsally defaults are already set)

//end setup by calling commit changes
ManagedInstance input = ref.createMethodInput("CommitChanges");
ManagedInstance output = ref.invoke(input);
//if the ReturnValue is 2057 (missing data) then we need to set data

A working sample can be dowloaded here. To run the java code edit the ztc.propertes file to reflect the name of your AmtSystem and path to your setup certificate file. Another thing to remember is that the AMTsystem’s network interface has to be active before you can do remote-configuration. You can open the Amt network interface in the Mebx by pressing CTRL-P on boot then “Intel® AMT Configuation->Remote Setup And Configuration->TLS-PKI->RCFG”. Alternatively , you can copy the ZTCLocalAgent.exe and StatusStrings.dll from %SDK_ROOT%\Windows\Intel_Manageability_Configuration\Bin and run "ZTCLocalAgent.exe -activate" on the target AMTsystem and that will open the network interface. If you use ZtcLocalAgent.exe you will need to “run as admin”. Otherwise you will get an error saying the HECI device is not found.

The purpose of this sample is to show how to issue wsman commands over a remote setup connection. For a complete Java server based solution you would want the wsman commands to be executed when a message has been sent from a local agent that has discovered AMT and has opened its network interface.

As stated earlier we can use the AMT SDK to generate a test certificate.
Note: all the steps below are just for manually creating a test certificate. If you have a real AMT setup certificate you can skip all this.
Open a command prompt.
Edit checkztc.bat by changing the line
Change to match your DHCP domain suffix.

cd %SDK_ROOT% \Windows\Intel_Manageability_Configuration\Bin\CertGenerator\ZtcSecScripts>
Configuration server needs a ZTC certificate in order
to be able to set up Intel® AMT devices in PKI-CH method.
You can create demo Root CA and have it sign demo ZTC Certificate.
*NOTE* for enabling the certificate, you'll need to add the hash of the
created Root CA to FW Certificate Hash List.
Create a demo Root CA and use it to sign ZTC Certificate [Y/n] ? (choose (Y)es)

Note: You can ignore the following warning.
WARNING: can't open config file: ..\x86DllMT/..\x86DllMT/ssl/openssl.cnf

>openssl pkcs12 -export -in fullchain.pem -inkey .\ZTC\private\ZTC_key.pem -out ztc.pfx
WARNING: can't open config file: ..\x86DllMT/..\x86DllMT/ssl/openssl.cnf
Loading 'screen' into random state - done
Enter Export Password: (type something simple to remember like 123)
Verifying - Enter Export Password: 123
unable to write 'random state'

After you have generated the test setup certificate you need to enter its Root CA thumbprint into the MeBx.
Open %SDK_ROOT%\Windows\Intel_Manageability_Configuration\Bin\CertGenerator\ZtcSecScripts\rootCa\rootCert.cer
Go to the details tab and write down the thumbprint data.
Then CRTL-P on boot and “Intel® AMT Configuration->Remote Setup And Configuration->TLS-PKI->Manage Hashes” and enter the data.

For more complete information about compiler optimizations, see our Optimization Notice.