Im busy trying to implement a custom version of the Intel AMT SCS in C# and I have a question regarding the TLS security.
The provisioning process using SSL/TLS-PSK to authenticate between the AMT client and the SCS server and this secure channel is used for all the configuration SOAP calls.
So my question is, how does one go about securing your SOAP calls in C# with SSL/TLS-PSK? I have done extensive research on the internet and can find no information on this. I had a closer look at the source code that is generated from the WSDL files in C# and the generated classes all inherit from the System.Web.Services.Protocols.SoapHttpClientProtocol class. This means that actual sending process is beyond my control.
I understand that the best approach is to use OpenSSL with the TLS-PSK API, but how would I go about securing the actual SOAP calls? I found some information on using IIS but that is not an option for me. Any help will be greatly appreciated.
The TLS-PSK protocol is only used during setup and configuration. Once setup and configuration is complete, applications must use the standard TLS/SSL certificate based protocol to interact with Intel AMT. (e.g. https://
It is not possible to communicate using TLS-PSK in C#. However, TLS-PSK is only needed by setup and config servers and not by Intel AMT applications. There is no need for an Intel AMT application to support TLS-PSK. The Intel SCS service is talks TLS-PSK using its own internal compiled in OpenSSL stack.
Thanks for your reply, but this is not good news. Here is my problem with as a developer for an Intel ISV; Intel would likeindependent development around the AMT technology and would like to see it widely used and implemented, however the entire implementation of the Intel SCS seems to hinder this.
The problem with the existing SCS is that it forces the end user to use very specific technologies i.e. Microsoft SQL server and IIS.We can not tell all our customers to convert to Microsoft SQL server and tell them that they must have IIS installed in order to use the Intel AMT SCS server.Our goal has always been to keep our software simple, easy to use and flexible.This is just one reason why we can not use the existing Intel SCS server and Management Console architecture.
So, eager to integrate Intel AMT support into our Desktop Management system we hoped to circumvent these issues by creating a custom SCS server. However you mentioned that "The Intel SCS service is talks TLS-PSK using its own internal compiled in OpenSSL stack"... This indicates that it is near impossible for any third party to implement their own SCS as it is build on non standard technology (i.e a custom Intel OpenSSL stack).
This brings me to my question, As an Intel ISV who has a non disclosure agreement with Intel, is there any information available, or is there a person who I can contact, who can help me understand this custom OpenSSL stack that Intel has created so that we too may create a similar implementation or use the existing Intel version?
I have forwarded your concerns to the SCS guru - do you have an Intel person that you could continue this discussion with? Since I don't see your email address I cannot contact you for further discussion. (and I'm not sure you would want to post it in the forum...)
To solvethis problemyou will need to look at the ConfigurationServer sample code in the AMT SDK. This has all the source code necessary and also has the OpenSSL stack needed for anyone wanting to develop their own SCS.
I just added a rather long entry to my blog on the topic of Intel AMT "Enterprise mode" setup with TLS-PSK. In the course of building my own sample setup and configuration tool in .NET, I ran into exactly the problem described in this thread. I solved it using a variation of the "ConfigurationServer.exe".
Once the new version of the DTK is released with my modified "ConfigurationServer", maybe you can take it and use it just like I did. I invoke it in C# and was able to supress the console window from showing up, I just look at the return code to see if it was successful or not.